5 ms·
I believe this is not correct for future scheduled events for humans. When a human sets an event for 8AM on some day 3 years in the future (maybe through a recu
by wolf550e 5y ago
I believe this is not correct for future scheduled events for humans. When a human sets an event for 8AM on some day 3 years in the future (maybe through a recurring weekly event), what they mean is "8AM local time in that jurisdiction". When a law passes that changes the daylight saving time amount or DST switch date or just sets the timezone to be different or the jurisdiction is merged into another or whatever, humans expect future scheduled events to adjust accordingly. Imagine a clock tower in the town square. If something political happens, it will be adjusted, and a meeting set to 8AM local time should occur according to that (possibly virtual) clock tower clock.
That is why logs (moment of time in the past) should be stored in UTC (possibly with local or user's timezone name for UI), timers (short offsets into the future from a moment of time in the past) should be stored in UTC like logs, and future scheduled events between humans should be stored in local time with the name of the timezone. The name of a timezone is never the offset, it is always the jurisdiction that can change the rules and be merged into another, etc.
When answering the question "what is the UTC time of a future scheduled appointment?", which is equivalent to "does it intersect a future scheduled appointment set in a different timezone on the same or adjacent dates?", which is also equivalent to the question "how many seconds in the future is this from right now?", you must assume the timezone rules set by politicians will not change between now and the appointment time. If the appointment time is soon (e.g. under 3 months), you indeed can assume this, because legislating an unexpected timezone change that will take effect "soon" is stupid and will usually not be done. But for a scheduled appointment a year from now? You honestly don't know. You can guess, but you must assume this can change by a TZ database update and act accordingly. If you have converted from localtime to UTC when the appointment was created, it is difficult to adjust correctly when TZ db is updated. If you translate to UTC only "just in time" when rendering or detecting collisions, everything will work correctly.
- dotancohen 5y agoActually, logs should be Unix timestamps in my opinion. It is a record of an event that occurred at a specific instant, regardless of how the user wants to see it formatted.
- rhn_mk1 5y agoUTC does not impose formatting on its own.
- melenaos 5y agoHow often the DTS changes? It should be a very rare event.
- taejo 5y agoIn most jurisdictions the DST rules and timezone offset change rarely. In some jurisdictions, they change more frequently. Over the whole world, they change often (dozens of times per year).
- spiralx 5y agoWorldwide there are several each year IIRC. There are a lot of small regional timezones you have to account for - at least two Native reservations have their own timezones, each offset by 15 minutes from the timezone of their surrounding region I believe, or at least they did a decade ago when I worked with all this. Also political changes often bring TZ changes, most obviously when larger countries split into smaller ones. But changing trade patterns can lead to TZ and DST changes, such as when Samoa skipped forward 24 hours, skipping Dec 30 2011 completely, putting them in the same timezone as Australia and New Zealand. https://www.theguardian.com/world/2011/dec/30/samoa-loses-day-date-line https://www.theguardian.com/world/2011/dec/30/samoa-loses-da... It also had July 4 1892 occur twice, due to originally having moved back 24 hours to align with the US.