21–30 of 117 posts
This strategy fails for appointments during that hour where the clock goes back: they are ambiguous, can refer to two different moments in time. That caveat aside: good.
Also, I have yet to encounter this problem. For personal events, I sleep during this time. For company events, we always avoid this time.
Earlier quoted context omitted.
The issue described in the post is an example of when you cannot just rely on Unix timestamps. Specifically it comes down to which date is authoritative. A appointment with your dentist at 2pm Pacific Time in December 2026 has changed Unix timestamps in British Columbia. The dentist doesn't care about the Unix timestamp, she cares about the wall clock local time when you arrive for the appointment.
"Which date is authoritative". I don't understand this. The consumer books in his/ her local time stamp i.e. 12 PM pacific. Gets stored as Epoch milliseconds (and is passed around as a data structure i.e. Date struct with UTC as the timezone) and the providers sees the time stamp 3 PM EST or 2 PM CST depending on it's timezone at runtime (interface the provider it works with). I don't understand why a specific timezo…
Between the time of booking and the time of the appointment, the government changed what timezone there will be at the time of the appointment. If you calculated the Unix timestamp at the time of booking using the old laws, by the time of the appointment the Unix timestamp would be off by an hour.
This strategy fails for appointments during that hour where the clock goes back: they are ambiguous, can refer to two different moments in time. That caveat aside: good.
I have yet to find a technological solution to this social problem. Also, I have yet to encounter this problem. For personal events, I sleep during this time. For company events, we always avoid this time.
A bit contrived but consider you are a maintenance worker in a facility that uses isolated timekeeping devices. "Change the clock on the vault back one hour at 3:00am".
This strategy fails for appointments during that hour where the clock goes back: they are ambiguous, can refer to two different moments in time. That caveat aside: good.
Future events: store the local (at the event) date and time and timezone. You’ll keep the right context even if lawmakers decide to switch things up. You want to see your doctor at 8:30 AM on Monday September 14, 2026 whether it’s daylight saving time, or standard time or “they” decide on a fractional hour offset between the time you set the appointment and the time you attend the appointment. Past events: UTC timest…
UTC timestamps should only ever be used for points in time in the most literal sense, and nothing else.
I would contend that you shouldn't store anything but current unix timestamps in UTC in your database. If you must store time in some other way, then the two column method in the post will work, but leave it up to your software library to do it. I prefer to leave all the time conversions to software, wherein you only use battle tested libraries, and never do it by hand. Timezones are just too fraught with peril to tr…
This strategy fails for appointments during that hour where the clock goes back: they are ambiguous, can refer to two different moments in time. That caveat aside: good.
I have yet to find a technological solution to this social problem. Also, I have yet to encounter this problem. For personal events, I sleep during this time. For company events, we always avoid this time.
The customer probably never noticed if I even did it “correctly” or couldn't be bothered if I didn't, but I remember I was bothered by it: (1) ensuring continuity of programming during the gap when it jumps forward (2) solving the ambiguity when it went backwards.
Because obviously they wanted to think in local time.
The southeast corner follows Alberta time (previously MST/MDT but changing to MDT).
Parts of the northeast and iirc a few other communities (eg Creston) have historically followed MST (no switch) and will now be effectively on the same time as Vancouver, albeit probably with a different TZ designation(?).
Source: me, BC resident.