All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.
What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist?
But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have good tooling for collaboratively choosing a meeting time). If you do this in your favourite chat app then you probably have no timezone support. (This would be an awesome feature though)
Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.
Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)
Yes, you do need to store the location of the scheduler so that you can adjust everything as appropriate, and of course you need to schedule the time the event was created. But you still only store those times in GMT.
By the way, what I’m describing is the way every AWS system does it.
Edit : Oddly, I can’t reply to your reply to this, but I already addressed the case you were talking about in this comment.
If I schedule an event in 1 year at 08:00 in MyCityTimezone and you store that the event occurs at 13:00 GMT then 3 months later MyCity decides that they aren't doing Daylight Savings Anymore your GMT time is now wrong. My event must still occur at 08:00 which is now 14:00 (or whatever) GMT.
"Just" storing it in GMT isn't enough. You probably do want to do that but you need to store the local time as well and update GMT to match if timezones change.
This is very frequently done wrong because timezones don't change often so the "Just store GMT" mostly works. But if you are writing a high quality system you need to deal with these cases.
No.
If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.
(This also raises the point that you need to preserve zone information, not just the UTC offset. Otherwise the meeting will move after a daylight saving time change, which is not usually what people want.)
Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.
From https://github.com/kstenerud/compact-time/blob/master/compac...
Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.
There are three main kinds of time:
*Absolute Time*
Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).
*Fixed Time*
Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.
*Floating Time*
Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.
*When to Use Each Kind*
Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.
Examples:
Recording an event: Absolute
Log entries: Absolute
An appointment: Fixed
Your daily schedule: Floating
Deadlines: Usually fixed time, but possibly absolute time.
And fixed time I would call local time. Why call it fixed? Because it's tied to a location?
So I went with floating vs fixed because it feels less prone to ambiguity. "Fixed" is fixed to a particular zone, and "floating" floats along with me as my current zone changes.
Several people have already replied pointing out that for scheduling events in the future, particularly recurring events, it's practically necessary to refer to time zones.
So I'll just mention the problem of leap seconds, which are announced six months in advance. If a one-second error could cause problems then probably you should use TAI rather than UTC. But you still need UTC for other purposes, so probably you need both and so you need to keep track of whether a particular timestamp is TAI or UTC.
You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that.
Your rule table might have a column for a cron expression, and a column for the tz database name.
Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.
If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.
UNIX timestamps are ambiguous.
ISO 8601 is perfectly good interchange format.
Besides the "meeting time" exception others have mentioned, you should be aware of timezones when grouping records into days/weeks/months/years/etc. The timezone affects where you "cut" the continuum into groups. Does Joe's sale count toward his January quota or February? This has all kinds of interesting questions: do you use the user's time zone? The local office timezone? The HQ timezone? UTC for everything? What if the user moves? Stack Overflow's "fanatic" badge just uses UTC: https://stackoverflow.com/help/badges/83/fanatic
Use UTC everywhere, then display in the user's timezone is a perfectly valid pattern...for specific use cases. Those use cases are very common, but many people over generalize, and assume that it can handle all cases.
I still don't understand the arguments about a future date requiring a timezone. UTC can 100% accurately represent a future date or event without any ambiguity. If a user, meeting or other aggregate has a culture/timezone preference, this is a completely separate business fact from the time.
A future event at local time requires a location, because the timezone may yet change at that location. Suppose we meet Nov 1st 2017 in Istanbul and decide to repeat this the year after. We agree to meet again Nov 1st 2018 in Istanbul 10:00 local time. This meeting would have been projected to happen at UTC 8:00, because Turkey was scheduled to switch to UTC+2 on October 30 2018.
However, the government decided to not change the timezone and stay on UTC+3. So our meeting, being scheduled for 10:00 local time, would move from UTC 8:00 to UTC 7:00 at the stroke of a pen. If your software had recorded UTC time, it would be ignorant of this change and consequently it would show the meeting at 11:00 local time. You'd be one hour late.
This change in the tz DB is a little window into the questionable cultural achievement that is local time: https://github.com/eggert/tz/commit/e15ef79a603a2fba89ad8f38...
It's not that a future date requires a time zone, you are right that can be 100% represented with a fixed timestamp. But there is the extreme case that time zone rules may change from the time you schedule the event to the time it happens, and in that case your event is now at the wrong time.
Consider the case where you have a weekly meeting at 9:00 AM on Tuesdays in an America/Chicago office. You could surely calculate the next N weeks of meetings and save them as UTC timestamps, taking into account that we shift into daylight savings time at some point, so you end up with a nice list of timestamps at 9:00 local time. But if the time zone rules change at any point (say, Chicago decides not to observe daylight savings time any more), now all of your meetings are an hour off.
If you had saved the meetings in a more verbose but true-to-intent format that properly captures "Every Tuesday at 9:00 AM America/Chicago", then at the time those rules changed you would either automatically have updated meeting timestamps, or some consolidation process could go and update the meeting times.
Even without sweeping changes like that, we still have unscheduled leap seconds, minutes, etc. every once in a while, which will also mess up your timestamps. I'm actually excited to see the day my calendar somehow ends up with a meeting at exactly 9:00:01.
I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...
If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.
I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a native type, can be compared using the fastest arithmetic instructions possible, and are a locale agnostic representation suitable for direct business logic comparisons.
Trying to carry timezone information around is a mistake. This is state that should be terminated and normalized at both ends, not passed through the system.
The only thing I would store pertaining to timezone is for user profile or server environment configuration. These would be settings in the application that are used to produce locale-specific UI and reports.
There are probably some other use cases I am not thinking of, but that is the extent of how we do it and we have a really complex app that has to serve customers who operate in multiple timezones at once.