4 ms·
Common mistake that I don't think the author got right either, is that if you want something to happen at a future local time time, say 2PM in São Paulo at som
by treve 3y ago
Common mistake that I don't think the author got right either, is that if you want something to happen at a future local time time, say 2PM in São Paulo at some date next year, you don't use UTC + a timezone, you use local time + timezone.
Timezones are not immutable, and timezone database updates happen every year. Only if you track dates that happen in the past UTC makes sense.
In some cases/jurisdictions they change DST quite late so you'll only know with certainty what UTC time corresponds with what local time a few weeks in advance.
- Terr_ 3y agoYeah, I often like to emphasize that many "scheduled events" are not simple numbers, but pattern-matching conditions, a contract of triggering-rules for something an unknowable number of elapsed seconds from "now." To be specific, it's "whenever the desk-calendars and wall-clocks in that jurisdiction will say X because the local government says so." The government of Bizarro São Paulo could decide to pause the clocks at 1:00PM, wait for one sunset and one sunrise, then set their clocks to 12:00PM, and then advance it by one "minute" every time a rooster crows until it reaches 12:10pm at which point they skip straight to 3:00pm. When is your schedule your 2PM wall-clock meeting? Probably around the tenth rooster-crow. If you had reason to distrust the clock-culture of Bizarro São Paulo, you shoulda made it a different timezone. :P
- esafak 3y agoCan off-the-shelf libraries translate from any Bizarro time to UTC?
- marcosdumay 3y agoNot in advance. Or better, they can translate it in advance, but they will translate to an incorrect value.
- esafak 3y agoSo what do you do, record both the local time and UTC?
- Veserv 3y agoYou record a context sensitive date/condition based on the user intent (i.e. birthday travels with the user, in person meeting based on meeting location, international call based on local time or UTC, explicit timezone keeps the timezone, etc.). How you map user intent to recorded date is problem specific. When the event happens you record the TAI. You may also wish to record the context sensitive date for auditing purposes, but it is not strictly necessary. You can rederive the occurred date if the event occurred in the past.
- deleted 3y ago[deleted]
- Terr_ 3y agoIMO the way to avoid insanity is explicit modeling, the pain comes from where different code was written with different beliefs about what the value "really means." For example, if there's a lunchtime event in Bizarro São Paulo you record "Noon in Bizarro Brazil Time" or even ("Noon in whatever timezone that office building will exist in") because it really does depend on the rhythm of the city. In contrast, if it's an international video-conference, you might record it as a time in UTC or the timezone/city of the most-critical participants. In both cases, users of the system should be able to see the "contract" along with the predicted moment in a probably-useful local representation. (I might not be in Bizarro São Paulo while I'm looking at the event, but I might know I'll be flying there later...) If you're afraid a Bizarro-govt is going to do something weird at the last second and cause all sorts of customer complaints for missed events, you might code a system that keeps track of when predicted-times (in something safer like UTC or TAI) suddenly change for events in a way that might catch users by surprise, and then send out notices.
- scatters 3y ago
- Veserv 3y agoTo elaborate further on your point, the key takeaway is that you can not, in general, predict what second a future date will occur because dates are societal and civil constructs meant for coordinating human activity. Counterintuitively, this is not true for the past and present. A specific second is unique. As long as you know the second you can derive the exact date (in the past) it occurred in whatever civil time standard you are using. The past and present should always be stored in TAI. The future should usually be stored as “pattern-matching conditions” (though you can use TAI if you are recording a elapsed time/seconds until the event).
- deleted 3y ago[deleted]
- throw-ru-938 3y agoYou use local time + location, because tzdata timezones can and do get split.
- midasuni 3y agohttps://mm.icann.org/pipermail/tz/2020-October/029376.html https://mm.icann.org/pipermail/tz/2020-October/029376.html For example - 5 days notice for a DST change.
- struant 3y agoLocal + Timezone is still going to be wrong if the people are viewing/planning this scheduled event are in different timezones and the timezone DB makes changes to either the viewers' or creator's timezone. In my opinion, it is better to just store UTC when you can't possibly make the date right in advance for all users in all timezones anyway. And if everyone does this, hopefully it discourages government from changing the timezone DB frivolously and without spending a lot of money broadcasting the changes to anyone that may be affected.
- tshaddox 3y agoI think this case is sufficiently complicated that we can't simply declare that the author got this wrong and that you should always use local time + timezone. What if that local time zone changes its DST rules to completely skip over that 2pm? Can we really confidently say that the user's intention when scheduling that event was that the event should be skipped if such a time zone change occurs between now and then?
- deleted 3y ago[deleted]