7 ms·

The most annoying timezone issue I encountered is that the timezone offsets can change (typically only for future times). So you if you store local times as UTC

The most annoying timezone issue I encountered is that the timezone offsets can change (typically only for future times). So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update (especially dangerous if you use the OS provided timezone data, since that makes it more difficult to control when it's updated). Always store the authoritative version of a time, which usually is UTC for points in time, but local time for calendar based things. The duplicate/missing hour around DST switching can also be quite annoying.

mjevans 6y ago
For an absolute event that was observed, UTC is, indeed, correct. For anything interacting with planning though, the user's needs should be considered. Often what you actually want to store is a "recurrence rule" for a single event, while being sure to include the defining aspects picked, or at least confirmed, by the user.
maxmax_ 6y ago
> The duplicate/missing hour around DST switching can also be quite annoying. Oh yes. I used to work for company which produced medical software which continuously recorded patient data. Those duplicated or missing hours were always the worst and error-prone use cases.
- Mountain_Skies 6y ago
  More than one vendor has become rather upset when I've demanded that they handle those situations appropriately. But much of what I do involves automation so I don't want any surprises or in this situation, two known exceptional cases that need to be accounted for. Also I find this to be a code smell, like brown M&Ms in a contract rider. Don't know if they've fixed it but when I had a Fitbit, they never was able to get these DST change over events handled correctly. What's worse is that their website and their app both handled the change over in different ways, both wrong.
  - CodesInChaos 6y ago
    What do you mean by handle appropriately here? This is one of the cases where I'd simply store UTC and display the (sometimes ambiguous) local time in the UI.
    - Mountain_Skies 6y ago
      The problem was that they weren't storing events in UTC but were using local server time instead. They had no explanation for what would happen during the switch from daylight time to standard time but couldn't rule out the possibility of out of order events happening due to it.
dmm 6y ago
> So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update That shouldn't be a problem for datetimes in the past. tzdata contains not only the current offset but all historical ones as well. It might be a problem for /future/ datetimes. If I say the meeting is at 1700 America/New_York and the local civil authority changes the offset in the meantime I probably don't want the meeting to move in local time.
- jmiserez 6y ago
  Unfortunately no, it can be a problem even for past dates. The new java.time and old java.util.TimeZone APIs use different offsets for dates < 1990, which resulted in a difference of 6 minutes and 32 seconds for my dates. I filed a bug (JDK-8214243) but basically it's a known issue and there's no fix.
  - CodesInChaos 6y ago
    When migrating from .net's TimeZoneInfo (based on windows timezones) to NodaTime (based on tzdb) we ran into differences in the mid nineties for the German timezone.
netsharc 6y ago
Yeah, 1 realization I made a long time ago was a day could have 25 hours or 23 hours. And a clever system having a timeline would show, e.g. in the Central European timezone: 1 AM, 2 AM (CET), 2 AM (CEST), 3 AM, 4 AM... or 1 AM, 2 AM (CEST), 4 AM (CET), 5 AM, ...
- Piskvorrr 6y ago
  There's an intriguing way that railways handle the transition around here (central Europe): one way, trains stop in stations for an hour, the other, they all get an +1 hr delay at next station.
  - nelaboras 6y ago
    Sorry but do you have a citation on that? Never seen anything like that in Europe.
    - netsharc 6y ago
      Not original commenter, but basically he's right, according to the German Rail (in German): https://www.deutschebahn.com/pr-hamburg-de/hintergrund/themendienste/Zeitumstellung-1310956 https://www.deutschebahn.com/pr-hamburg-de/hintergrund/theme... If a night loses 1 hour, the train stops for less time at the scheduled stops, or arrives with a delay. If the night gains an hour, the train waits somewhere for an hour. Which sounds like a painful thing, having to travel (or wait) an extra hour because of clocks. Interestingly if the night loses an hour, the trains are automatically an hour behind schedule...
      - andi999 6y ago
        Beeing an hour behind schedule is not that uncommon.....
    - Piskvorrr 6y ago
      Other than [OWNRESEARCH], i.e. experienced that a few times? Not really, no.
Piskvorrr 6y ago
Missing hour, ha! The Norwegians have apparently named their Antarctic station Troll for a reason: the TZ Antarctica/Troll uses UTC/UTC+2 - great way to test/break things that need to work with dates.
- CodesInChaos 6y ago
  To really troll software developers they should repeat one hour three times, instead of repeating two hours twice.
  - willis936 6y ago
    I feel like this would also troll everyone in their society. >What time is it? 2am. >It’s been 2am for 2 hours!

mjevans 6y ago

For an absolute event that was observed, UTC is, indeed, correct. For anything interacting with planning though, the user's needs should be considered. Often what you actually want to store is a "recurrence rule" for a single event, while being sure to include the defining aspects picked, or at least confirmed, by the user.

maxmax_ 6y ago

> The duplicate/missing hour around DST switching can also be quite annoying. Oh yes. I used to work for company which produced medical software which continuously recorded patient data. Those duplicated or missing hours were always the worst and error-prone use cases.

Mountain_Skies 6y ago
More than one vendor has become rather upset when I've demanded that they handle those situations appropriately. But much of what I do involves automation so I don't want any surprises or in this situation, two known exceptional cases that need to be accounted for. Also I find this to be a code smell, like brown M&Ms in a contract rider. Don't know if they've fixed it but when I had a Fitbit, they never was able to get these DST change over events handled correctly. What's worse is that their website and their app both handled the change over in different ways, both wrong.
- CodesInChaos 6y ago
  What do you mean by handle appropriately here? This is one of the cases where I'd simply store UTC and display the (sometimes ambiguous) local time in the UI.
  - Mountain_Skies 6y ago
    The problem was that they weren't storing events in UTC but were using local server time instead. They had no explanation for what would happen during the switch from daylight time to standard time but couldn't rule out the possibility of out of order events happening due to it.

dmm 6y ago

> So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update That shouldn't be a problem for datetimes in the past. tzdata contains not only the current offset but all historical ones as well. It might be a problem for /future/ datetimes. If I say the meeting is at 1700 America/New_York and the local civil authority changes the offset in the meantime I probably don't want the meeting to move in local time.

jmiserez 6y ago
Unfortunately no, it can be a problem even for past dates. The new java.time and old java.util.TimeZone APIs use different offsets for dates < 1990, which resulted in a difference of 6 minutes and 32 seconds for my dates. I filed a bug (JDK-8214243) but basically it's a known issue and there's no fix.
- CodesInChaos 6y ago
  When migrating from .net's TimeZoneInfo (based on windows timezones) to NodaTime (based on tzdb) we ran into differences in the mid nineties for the German timezone.

netsharc 6y ago

Yeah, 1 realization I made a long time ago was a day could have 25 hours or 23 hours. And a clever system having a timeline would show, e.g. in the Central European timezone: 1 AM, 2 AM (CET), 2 AM (CEST), 3 AM, 4 AM... or 1 AM, 2 AM (CEST), 4 AM (CET), 5 AM, ...

Piskvorrr 6y ago
There's an intriguing way that railways handle the transition around here (central Europe): one way, trains stop in stations for an hour, the other, they all get an +1 hr delay at next station.
- nelaboras 6y ago
  Sorry but do you have a citation on that? Never seen anything like that in Europe.
  - netsharc 6y ago
    Not original commenter, but basically he's right, according to the German Rail (in German): https://www.deutschebahn.com/pr-hamburg-de/hintergrund/themendienste/Zeitumstellung-1310956 https://www.deutschebahn.com/pr-hamburg-de/hintergrund/theme... If a night loses 1 hour, the train stops for less time at the scheduled stops, or arrives with a delay. If the night gains an hour, the train waits somewhere for an hour. Which sounds like a painful thing, having to travel (or wait) an extra hour because of clocks. Interestingly if the night loses an hour, the trains are automatically an hour behind schedule...
    - andi999 6y ago
      Beeing an hour behind schedule is not that uncommon.....
  - Piskvorrr 6y ago
    Other than [OWNRESEARCH], i.e. experienced that a few times? Not really, no.

Piskvorrr 6y ago

Missing hour, ha! The Norwegians have apparently named their Antarctic station Troll for a reason: the TZ Antarctica/Troll uses UTC/UTC+2 - great way to test/break things that need to work with dates.

CodesInChaos 6y ago
To really troll software developers they should repeat one hour three times, instead of repeating two hours twice.
- willis936 6y ago
  I feel like this would also troll everyone in their society. >What time is it? 2am. >It’s been 2am for 2 hours!