Hacker News Reader

Comment by masklinn | Hacker News Reader

Except (2) doesn't necessarily work when events are local and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings.

Example: in early 2011, Samoa announced that on December 29th at midnight local they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your timezone database has been updated), store as UTC a meeting in local Samoa time, and the user will miss their meeting by a day.

Of course storing a meeting on December 30th local would also have been fraught as there is no December 30th 2011 in Pacific/Apia but that is a common occurrence historically due to the unsynchronised julian/gregorian switches e.g. none of the dates between February 16th and February 28th 1923 (included) exist in Greece, and the US doesn't have a 9/11 in 1752.

View on HN

I think the recommendation still holds.

You want a meeting at 1100 local time.

Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant)

Samoa changes the rules.

The calendar doesn't change.

This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't).

School times, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.

> You want a meeting at 1100 local time.

On a specific day.

> The calendar doesn't change.

Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time).

> This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

* while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local

* this is stored as 2012-01-05T22:00:00+0000

* tzinfo gets updated with Pacific/Apia at UTC+13

* your calendar now tells you your meeting is on January 6th at 11 local

* you're a day late

You're both correct.

The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick.

P) The event is at a precise internationally recognized moment (better for co-ordination globally).

R) The event is in local time (like a lunch date) and expected to remain colloquially fixed.

In the case of the first you store a precise UTC timestamp and drop the timezone (it's UTC).

In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.

Samoa did change the calendar. The local <-> utc mapping changed. In order to update the stored database, you need to convert all times to local with the old mapping, then convert to utc again with the new mapping.

Using one of the most extreme edge cases is not a good argument. How often is Samoa (or another small dateline-neighbour country) going to 'jump sides'?

> Using one of the most extreme edge cases is not a good argument.

1. How is it not a good argument? It's an actual historical fact which is not yet 5 years old rather than some intellectual exercise, you can hardly go better than "this stuff happened not 5 years ago".

2. The only "extreme" part here is the magnitude of the drift, it's a clear example and demonstration of the issue.

> How often is Samoa going to 'jump sides'?

How is that relevant to the problem specifically and clearly existing? Does it matter if your calendar is 24h off or 6h off? Your system is FUBAR either way.

> or another small dateline-neighbour country

The dateline isn't even relevant, are you somehow trying to win a prize in missing the point?

> It's an actual historical fact

It's actual historic fact that the gregorian calendar we use skipped 11 days, but I don't see your suggestion solving that. Again, it was "just magnitude".

> Does it matter if your calendar is 24h off or 6h off? Your system is FUBAR either way.

Your theoretical appointment-haver might not blink at an appointment at a normal time + 1 day in the future, but might blink when their appointments start in the early afternoon and continue until midnight.

The fact is that if you skip days, then it doesn't matter if you use local or UTC time.

> are you somehow trying to win a prize in missing the point?

I'm not the cretin who thinks that timekeeping is a binary good/bad state. Some applications have troubles when they're milliseconds out. Others have quite a bit of lag time that they can handle. A daily to-do list just needs to appear on the right day, for example; DST means little to it.

Timezones change all the time. There are almost 200 countries in the world, some so large that even their sub-states can and do change timezone rules on their own (US, Russia, India, China...). This is why Linux distributions have a dedicated package listing timezone info that is updated almost weekly, and Windows has similar arrangements.

Any solid datetime implementation better consider that time is not, in fact, immutable - even UTC can and will shift here and there.

I am aware of this, but picking an extreme example and discussing it like it's a standard occurrence just muddies the issues.

Reply on news.ycombinator.com