Hacker News Reader

Comment by CodesInChaos | Hacker News Reader

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.

View on HN

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.

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.

To really troll software developers they should repeat one hour three times, instead of repeating two hours twice.

I feel like this would also troll everyone in their society.

>What time is it?

2am.

>It’s been 2am for 2 hours!

> 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.

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.

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.

> 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.

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.

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.

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.

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...

1 AM, 2 AM (CEST), 4 AM (CET), 5 AM, ...

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.

Sorry but do you have a citation on that? Never seen anything like that in Europe.

Not original commenter, but basically he's right, according to the German Rail (in German): 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...

Beeing an hour behind schedule is not that uncommon.....

Other than [OWNRESEARCH], i.e. experienced that a few times? Not really, no.

Its like this in germany

According to a commenter above, the norwegian station of Troll[0] is on UCT in summer time but UTC+2 in winter time, so its "day" can have 22~26h.

Then there's the possibility of timezones straight moving around which can make entire days replay or disappear e.g. in Samoa there is no 2011-12-30, the day literally doesn't exist, Samoa local calendar goes straight 2011-12-29 to 2011-12-31, because at midnight the country switched from UTC-11:00 to UTC+13:00.

[0] https://en.wikipedia.org/wiki/Troll_(research_station)

Reply on news.ycombinator.com