6 ms·

Tangential, but man time zones are just really hard. Some theoretically “simple” rules seem to routinely violate human intuition, and the almanac actually chang

Tangential, but man time zones are just really hard. Some theoretically “simple” rules seem to routinely violate human intuition, and the almanac actually changes based on laws and stuff. Keeping everything in Zulu ms or ns and rendering into timezones as late as possible is a useful guideline as far as it carries one, but sometimes it’s not enough, this is one of a zillion reasons why e.g. calendaring is just really hard. I’ve long since mentally tagged “timezone handling”, in any language, as a slow zone: let’s stop and really think this through.

Cthulhu_ 3y ago
> Zulu ms or ns Is that timestamps as in unix timestamps? That won't work with birthdates for people more than 53 years old for example; a colleague mentioned a weird issue for someone born in 1938, but that was because the timezone in that location at that time was something like GMT+1:23, then the Germans came around and standardized it to +1:20, then later it was normalized to +1:00. tl;dr, time and date can only be accurate if time, date and location are known. Actually, some places have moved to different timezones over time as well, so you can't just say "this time has a timezone of GMT", you have to ask "what is the timezone of this location at this time/date"
- Aachen 3y ago
  To get to/from that local time representation, you can still store it as a timestamp (to know when it actually happened) and use a timezone database that tells you what the people living there in that moment labeled that time as, right?
  - IggleSniggle 3y ago
    You still have the fundamental issue of storing it correctly in the first place. Do most languages time libraries account for localized temporal shifts of this nature by default? It does seem true that you could query an authoritative source, but on entry: If I say the event happened 60 years ago exactly, and it’s 1pm, what do I mean by “exactly?” Do I mean the day 60 years ago, at 1pm? Or 60 years ago, taking into account timezone shifts? Do I, the person entering this information, even know or care about this distinction? If you enter an event as 60 years ago, would your average joe expect that the time would shift by 23 minutes, or would they think there’s something wrong with the software? What about timezone differences that vary depending not only on geography, but also on the ethnicity of the people associated with the event?
    - BlueTemplar 3y ago
      You mean ethnicities that are still deprived of nationhood, so the empire they are subjects of assigns different timezones to them compared to other ethnicities they rule ?? (Any examples ??)
      - ElevenLathe 3y ago
        The classic example (and it may in fact be the only extant one) is the occupied West Bank, where Israelis keep a different time than Palestinians (sometimes): https://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
        dragonwriter 3y ago
        Yeah, ISTR that there are (or have recently been) some at least theoretical (that is, where there were political claims with different timezones, but not necessarily populations in the affected area using both) ones besides that, but that may well be the only current one.
      - richiebful1 3y ago
        There's some informal use of a Xinjiang timezone among Uyghurs. China as a whole only has one official timezone. [1] https://www.timeanddate.com/worldclock/china/urumqi https://www.timeanddate.com/worldclock/china/urumqi [more background here] https://www.theatlantic.com/china/archive/2013/11/china-only-has-one-time-zone-and-thats-a-problem/281136/ https://www.theatlantic.com/china/archive/2013/11/china-only...
    - dragonwriter 3y ago
      > What about timezone differences that vary depending not only on geography, but also on the ethnicity of the people associated with the event? Typically, recently, this problem would occur in disputed territories where the “legal time” at a certain point differs because it is claimed by different polities with different timezone rules, so its more of political allegiance than ethnicity (though those correlate).
maweki 3y ago
For things in the past, Zulu is fine. But you won't know Zulu for a date in the future, because Timezone changes may happen. So Zulu for the past, datetime+location for the future.
magicalhippo 3y ago
It's even harder. Is the time the user entered actually an always-local time? As in, if I set my alarm for 08:00, I'd expect it to wake me up 08:00 local regardless if I'm in Oslo or I've traveled to say New York. However if I make a calendar event things are less clear cut. For meetings and such it makes sense that the time is global time (hence stored in UTC), but for tasks it can be be either or, depending.
- sdfghswe 3y ago
  I really like what google calendar does, which is to allow you to display both.
- comicjk 3y ago
  I was baffled when I first entered my schedule for a conference into Google Maps, only to find when I flew across the country that all the times were wrong. I understand that it's a reasonable choice to use the local time zone at event creation, but it sure wasn't what I expected (I vaguely thought it would be like your alarm clock example, where it would move with the local time).
  - arnsholt 3y ago
    I once made a flight by the slimmest of margins possible (the gate crew stopped closing the check in because they saw me sprinting through the terminal hall), because of this and only one hour difference between where I started from and where I went.
  - ehvatum 3y ago
    I mean obviously wherever a date time entry can be found, there should be a TZ drop-down and a DST checkbox. lusers who don’t know what those things are will learn soon enough. I really mean it. The ambiguity is a problem.
  - paulddraper 3y ago
    I've done the same. Google did 100% the correct thing, but it goes to show that this is just an inherently tricky thing not limited to whether you are writing code.
brookst 3y ago
Time zones, character encoding, localization. I admire people who dig in and really understand them deeply, but as far as I’m concerned they are all exposed high voltage wires that I avoid going near.
laci37 3y ago
Implement everything in Zulu, then watch as the frontend ticket for proper rendering stays on the bottom of the backlog, because you always have more concerning problems than users having to do mental math on times.
- dullcrisp 3y ago
  Are you giving this as genuine advice, or are you suggesting implementing time zones early instead as a form of penance?
  - deleted 3y ago
    [deleted]
hprotagonist 3y ago
> the almanac actually changes based on laws and stuff. some of my perennial favorites: - in samoa, there was never a december 30th 2011. - in indiana, time zone observance is determined per county - in arizona, the reservation land observes dst, and the state doesn’t, and reservation lands can enclose non-reservation lands. - lebanon recently had a legislative dispute about dst such that some entities in the nation did or did not observe dst for about a week.
- cudder 3y ago
  > - in samoa, there was never a december 30th 2011. That was interesting, so I had to read about it. Apparently they skipped a day to be closer to Asian time zones. They did the same thing in the opposite direction in 1892 by having two 4th of Julys to be closer to American timezones. Now they kinda just walked back on that. Interestingly I think the Python datetime approach can handle both of these with no problem. The rest of your list sounds... a lot tougher.
- RobotToaster 3y ago
  If you're storing historical dates, September 1752 only had 19 days.
  - hprotagonist 3y ago
    oh, historical time is an absolute mess. i have yet to find a library that handles BC dates except maybe astropy — and they have different priorities!
  - remram 3y ago
    The transition from the Julian to Gregorian calendar also happened on vastly different dates in different countries. Most of Western Europe changed in 1582, the British Empire (and its American colonies) in 1752 as you said, and other countries switched even later like Russia in 1918.
ska 3y ago
> Tangential, but man time zones are just really hard That can be expanded. Time and dates is just fundamentally hard.
smarx007 3y ago
I think keeping time in UTC as primary data for as long as possible is a really bad idea, as explained by Jon Skeet quite a while ago: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
hoosieree 3y ago
Non-programmers don't care about this nearly as much as we do. The prevailing attitude is "Ok sure there are edge cases, but so what? My use case is simple". And after thinking about it a lot more, I think this attitude is actually more sensible than mine used to be. Why do we as programmers keep trying to fit a square peg into a round hole? Timezones are a political construct, not a mathematical one. We should address edge cases by deferring to people as much as possible. Oh, you find it annoying to enter an offset? Don't worry about it, it's optional! Your dentist will expect you for your cleaning at 8:00am +/- 5 hours. If we keep smoothing over the rough edges for our users, the problem will only get worse. Better to make timezones as painful as possible for as many users as possible. They'll eventually vote for something less obnoxious.
- cudder 3y ago
  As much as I would love this too from a programmer's perspective, reading [1] convinced me that time zones are a necessary evil we just kinda have to deal with. They could be improved by a lot, though. First thing I'd do is get rid of DST everywhere. [1]: https://qntm.org/abolish https://qntm.org/abolish
  - FullyFunctional 3y ago
    Thanks for the reference. I have a number of issues with that essay, but fundamentally, once we have people on Mars we'll have exactly this issue. There's no easy way around it and we'll always have to negotiate hours that work for both parties (which is what I basically have to do with my family who are about 90º phase shifted from me).
- naniwaduni 3y ago
  > We should address edge cases by deferring to people as much as possible. Oh, you find it annoying to enter an offset? Don't worry about it, it's optional! Your dentist will expect you for your cleaning at 8:00am +/- 5 hours. > If we keep smoothing over the rough edges for our users, the problem will only get worse. Better to make timezones as painful as possible for as many users as possible. They'll eventually vote for something less obnoxious. This is gonna go over great with the people making purchasing decisions.
banannaise 3y ago
Time zones are themselves a footgun. There is no actual reason for morning to start at approximately the same time everywhere. 9am can be 9am everywhere. In some places 9am can be sunrise, in some it can be sunset, and in some it can be the middle of the night. No conversions, no confusion, no resetting of watches... We don't change the months in the southern hemisphere. Australia is cold in July, Europe is cold in January, this doesn't seem to bother us.
- MajimasEyepatch 3y ago
  It's a lot easier to remember "north and south are opposite" than it is to remember, "Oh right, 9 am is morning in England, early morning in New York, and the middle of the night in Los Angeles." And so on for every possible time of day. Whereas it's (relatively) easy to guess, "Los Angeles is in California, that's three hours behind me in New York, so it would be 6 am there at 9 am here, so it's too early to call them yet." Not perfect, but not too bad for simple cases, and easy to do in your head most of the time. Timezones are about standardizing _human_ time, not actual time.
- chefandy 3y ago
  > There is no actual reason There may be no technical reason for it, but having a common reference point for times of the day in terms of human experience and behavior is an actual reason. Saying you were walking down the street at 2am or 3am is immediately distinct from saying you were walking down the street at 10pm or 11pm in ways many people understand. Having to qualify it with the date and geographic location and/or sunrise or sunset patterns would be a much bigger PITA than your average person will ever experience because of time zone inconsistencies. It's just not that important for most people to be able to pinpoint a timestamp to one exact time throughout the world. We've got GMT. Nothing is stopping anybody from using that to schedule their lives. There's a reason people don't.
sangnoir 3y ago
> I’ve long since mentally tagged “timezone handling”, in any language, as a slow zone: let’s stop and really think this through. I will second you ok that: date & Time handling across timezones was one of the 2 hardest things I've ever worked on that are deceptively simple on the surface. The other was adding localization/making an app translatable to any language after shipping the first version with hard-coded text.
- hermitdev 3y ago
  Same here. Worrying about current timezones is a hard enough problem. Getting accurate historical timezones handling working is an even harder problem. Getting consistent results across Windows, Mac and Linux is an even harder problem. Needed it for proper handling of historical time series for financial data.
didip 3y ago
I agree. Local time with timezone is really a presentation-layer concern. For server-side and storage layer, it's saner for everyone to simply store in UTC or epoch seconds/nanoseconds.

Cthulhu_ 3y ago

> Zulu ms or ns Is that timestamps as in unix timestamps? That won't work with birthdates for people more than 53 years old for example; a colleague mentioned a weird issue for someone born in 1938, but that was because the timezone in that location at that time was something like GMT+1:23, then the Germans came around and standardized it to +1:20, then later it was normalized to +1:00. tl;dr, time and date can only be accurate if time, date and location are known. Actually, some places have moved to different timezones over time as well, so you can't just say "this time has a timezone of GMT", you have to ask "what is the timezone of this location at this time/date"

Aachen 3y ago
To get to/from that local time representation, you can still store it as a timestamp (to know when it actually happened) and use a timezone database that tells you what the people living there in that moment labeled that time as, right?
- IggleSniggle 3y ago
  You still have the fundamental issue of storing it correctly in the first place. Do most languages time libraries account for localized temporal shifts of this nature by default? It does seem true that you could query an authoritative source, but on entry: If I say the event happened 60 years ago exactly, and it’s 1pm, what do I mean by “exactly?” Do I mean the day 60 years ago, at 1pm? Or 60 years ago, taking into account timezone shifts? Do I, the person entering this information, even know or care about this distinction? If you enter an event as 60 years ago, would your average joe expect that the time would shift by 23 minutes, or would they think there’s something wrong with the software? What about timezone differences that vary depending not only on geography, but also on the ethnicity of the people associated with the event?
  - BlueTemplar 3y ago
    You mean ethnicities that are still deprived of nationhood, so the empire they are subjects of assigns different timezones to them compared to other ethnicities they rule ?? (Any examples ??)
    - ElevenLathe 3y ago
      The classic example (and it may in fact be the only extant one) is the occupied West Bank, where Israelis keep a different time than Palestinians (sometimes): https://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
      - dragonwriter 3y ago
        Yeah, ISTR that there are (or have recently been) some at least theoretical (that is, where there were political claims with different timezones, but not necessarily populations in the affected area using both) ones besides that, but that may well be the only current one.
    - richiebful1 3y ago
      There's some informal use of a Xinjiang timezone among Uyghurs. China as a whole only has one official timezone. [1] https://www.timeanddate.com/worldclock/china/urumqi https://www.timeanddate.com/worldclock/china/urumqi [more background here] https://www.theatlantic.com/china/archive/2013/11/china-only-has-one-time-zone-and-thats-a-problem/281136/ https://www.theatlantic.com/china/archive/2013/11/china-only...
  - dragonwriter 3y ago
    > What about timezone differences that vary depending not only on geography, but also on the ethnicity of the people associated with the event? Typically, recently, this problem would occur in disputed territories where the “legal time” at a certain point differs because it is claimed by different polities with different timezone rules, so its more of political allegiance than ethnicity (though those correlate).

maweki 3y ago

For things in the past, Zulu is fine. But you won't know Zulu for a date in the future, because Timezone changes may happen. So Zulu for the past, datetime+location for the future.

magicalhippo 3y ago

It's even harder. Is the time the user entered actually an always-local time? As in, if I set my alarm for 08:00, I'd expect it to wake me up 08:00 local regardless if I'm in Oslo or I've traveled to say New York. However if I make a calendar event things are less clear cut. For meetings and such it makes sense that the time is global time (hence stored in UTC), but for tasks it can be be either or, depending.

sdfghswe 3y ago
I really like what google calendar does, which is to allow you to display both.
comicjk 3y ago
I was baffled when I first entered my schedule for a conference into Google Maps, only to find when I flew across the country that all the times were wrong. I understand that it's a reasonable choice to use the local time zone at event creation, but it sure wasn't what I expected (I vaguely thought it would be like your alarm clock example, where it would move with the local time).
- arnsholt 3y ago
  I once made a flight by the slimmest of margins possible (the gate crew stopped closing the check in because they saw me sprinting through the terminal hall), because of this and only one hour difference between where I started from and where I went.
- ehvatum 3y ago
  I mean obviously wherever a date time entry can be found, there should be a TZ drop-down and a DST checkbox. lusers who don’t know what those things are will learn soon enough. I really mean it. The ambiguity is a problem.
- paulddraper 3y ago
  I've done the same. Google did 100% the correct thing, but it goes to show that this is just an inherently tricky thing not limited to whether you are writing code.

brookst 3y ago

Time zones, character encoding, localization. I admire people who dig in and really understand them deeply, but as far as I’m concerned they are all exposed high voltage wires that I avoid going near.

laci37 3y ago

Implement everything in Zulu, then watch as the frontend ticket for proper rendering stays on the bottom of the backlog, because you always have more concerning problems than users having to do mental math on times.

dullcrisp 3y ago
Are you giving this as genuine advice, or are you suggesting implementing time zones early instead as a form of penance?
- deleted 3y ago
  [deleted]

hprotagonist 3y ago

> the almanac actually changes based on laws and stuff. some of my perennial favorites: - in samoa, there was never a december 30th 2011. - in indiana, time zone observance is determined per county - in arizona, the reservation land observes dst, and the state doesn’t, and reservation lands can enclose non-reservation lands. - lebanon recently had a legislative dispute about dst such that some entities in the nation did or did not observe dst for about a week.

cudder 3y ago
> - in samoa, there was never a december 30th 2011. That was interesting, so I had to read about it. Apparently they skipped a day to be closer to Asian time zones. They did the same thing in the opposite direction in 1892 by having two 4th of Julys to be closer to American timezones. Now they kinda just walked back on that. Interestingly I think the Python datetime approach can handle both of these with no problem. The rest of your list sounds... a lot tougher.
RobotToaster 3y ago
If you're storing historical dates, September 1752 only had 19 days.
- hprotagonist 3y ago
  oh, historical time is an absolute mess. i have yet to find a library that handles BC dates except maybe astropy — and they have different priorities!
- remram 3y ago
  The transition from the Julian to Gregorian calendar also happened on vastly different dates in different countries. Most of Western Europe changed in 1582, the British Empire (and its American colonies) in 1752 as you said, and other countries switched even later like Russia in 1918.

ska 3y ago

> Tangential, but man time zones are just really hard That can be expanded. Time and dates is just fundamentally hard.

smarx007 3y ago

I think keeping time in UTC as primary data for as long as possible is a really bad idea, as explained by Jon Skeet quite a while ago: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

hoosieree 3y ago

Non-programmers don't care about this nearly as much as we do. The prevailing attitude is "Ok sure there are edge cases, but so what? My use case is simple". And after thinking about it a lot more, I think this attitude is actually more sensible than mine used to be. Why do we as programmers keep trying to fit a square peg into a round hole? Timezones are a political construct, not a mathematical one. We should address edge cases by deferring to people as much as possible. Oh, you find it annoying to enter an offset? Don't worry about it, it's optional! Your dentist will expect you for your cleaning at 8:00am +/- 5 hours. If we keep smoothing over the rough edges for our users, the problem will only get worse. Better to make timezones as painful as possible for as many users as possible. They'll eventually vote for something less obnoxious.

cudder 3y ago
As much as I would love this too from a programmer's perspective, reading [1] convinced me that time zones are a necessary evil we just kinda have to deal with. They could be improved by a lot, though. First thing I'd do is get rid of DST everywhere. [1]: https://qntm.org/abolish https://qntm.org/abolish
- FullyFunctional 3y ago
  Thanks for the reference. I have a number of issues with that essay, but fundamentally, once we have people on Mars we'll have exactly this issue. There's no easy way around it and we'll always have to negotiate hours that work for both parties (which is what I basically have to do with my family who are about 90º phase shifted from me).
naniwaduni 3y ago
> We should address edge cases by deferring to people as much as possible. Oh, you find it annoying to enter an offset? Don't worry about it, it's optional! Your dentist will expect you for your cleaning at 8:00am +/- 5 hours. > If we keep smoothing over the rough edges for our users, the problem will only get worse. Better to make timezones as painful as possible for as many users as possible. They'll eventually vote for something less obnoxious. This is gonna go over great with the people making purchasing decisions.

banannaise 3y ago

Time zones are themselves a footgun. There is no actual reason for morning to start at approximately the same time everywhere. 9am can be 9am everywhere. In some places 9am can be sunrise, in some it can be sunset, and in some it can be the middle of the night. No conversions, no confusion, no resetting of watches... We don't change the months in the southern hemisphere. Australia is cold in July, Europe is cold in January, this doesn't seem to bother us.

MajimasEyepatch 3y ago
It's a lot easier to remember "north and south are opposite" than it is to remember, "Oh right, 9 am is morning in England, early morning in New York, and the middle of the night in Los Angeles." And so on for every possible time of day. Whereas it's (relatively) easy to guess, "Los Angeles is in California, that's three hours behind me in New York, so it would be 6 am there at 9 am here, so it's too early to call them yet." Not perfect, but not too bad for simple cases, and easy to do in your head most of the time. Timezones are about standardizing _human_ time, not actual time.
chefandy 3y ago
> There is no actual reason There may be no technical reason for it, but having a common reference point for times of the day in terms of human experience and behavior is an actual reason. Saying you were walking down the street at 2am or 3am is immediately distinct from saying you were walking down the street at 10pm or 11pm in ways many people understand. Having to qualify it with the date and geographic location and/or sunrise or sunset patterns would be a much bigger PITA than your average person will ever experience because of time zone inconsistencies. It's just not that important for most people to be able to pinpoint a timestamp to one exact time throughout the world. We've got GMT. Nothing is stopping anybody from using that to schedule their lives. There's a reason people don't.

sangnoir 3y ago

> I’ve long since mentally tagged “timezone handling”, in any language, as a slow zone: let’s stop and really think this through. I will second you ok that: date & Time handling across timezones was one of the 2 hardest things I've ever worked on that are deceptively simple on the surface. The other was adding localization/making an app translatable to any language after shipping the first version with hard-coded text.

hermitdev 3y ago
Same here. Worrying about current timezones is a hard enough problem. Getting accurate historical timezones handling working is an even harder problem. Getting consistent results across Windows, Mac and Linux is an even harder problem. Needed it for proper handling of historical time series for financial data.

didip 3y ago

I agree. Local time with timezone is really a presentation-layer concern. For server-side and storage layer, it's saner for everyone to simply store in UTC or epoch seconds/nanoseconds.