1) Whenever dealing with users, use local tz.
2) Always save and manipulate in utc.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.
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.
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.
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
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.
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 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.
Any solid datetime implementation better consider that time is not, in fact, immutable - even UTC can and will shift here and there.
Two very common examples: For a recurring scheduled event, "Same time tomorrow" may require adding 24, 23 or 25 hours to the UTC time, depending on the TZ.
The question "how many full days have elapsed between two timestamps?" may need to return 1 for 23.5 hour distance or 0 for 24.5 hour distance depending on the TZ.
I'd be so happy if we all could agree that a day always has 24 hours, but that doesn't seem likely any time soon.
And even if you only need timestamps, "Whenever dealing with users, use local tz" isn't exactly a magic wand either.
Also, "unix timestamp" isn't exactly one data type. Sometimes you need greater precision than one second.