4 ms·

The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezon

The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezone tomorrow, the timer will expire at the wrong time. We should store the actual time of an event and update it when the scheduled time changes.

jasode 8y ago
>, the timer will expire at the wrong time. A countdown timer is a runtime concept. Storing pure UTC and/or intended_localtime_plus_TZ in the database is a static concept of data-at-rest. A timespan/timer is a different abstraction than a desired point-in-time. Depending on the use case, the correct timer/timespan value can be derived from pure UTC (e.g. scientific celestial events) -- or -- user_specified_localtime_plus_TZ (recurring yoga class at 5:30pm every Wednesday, or take medication every morning at 7:00am). For user calendaring and scheduling of social appointments, storing pure UTC will lead to data loss and errors. Instead of complicated mass updates of millions of db rows, it's much more straightforward to take a stored localtimeTZ, and then calculate an up-to-date UTC time at runtime, and then derive a countdown timer from that. The key insight is that the best time to use UTC is when the users need that timer at runtime -- and not when they store the row in the db.
- deleted 8y ago
  [deleted]
falcolas 8y ago
> We should store the actual time of an event and update it when the scheduled time changes. I would love to see some (simple) code which will send a single alert to me at 1:30 am and another at 2:30am. My client registered me as MST (-7) when I set these two alarms in Feburary. Of particular note for corner cases: Nov 4th and Mar 10, 2019. The "scheduled time" will change, for many locations, twice yearly. EDIT: For added fun, instead consider the registration date as May 10th with the same timezone.

jasode 8y ago

>, the timer will expire at the wrong time. A countdown timer is a runtime concept. Storing pure UTC and/or intended_localtime_plus_TZ in the database is a static concept of data-at-rest. A timespan/timer is a different abstraction than a desired point-in-time. Depending on the use case, the correct timer/timespan value can be derived from pure UTC (e.g. scientific celestial events) -- or -- user_specified_localtime_plus_TZ (recurring yoga class at 5:30pm every Wednesday, or take medication every morning at 7:00am). For user calendaring and scheduling of social appointments, storing pure UTC will lead to data loss and errors. Instead of complicated mass updates of millions of db rows, it's much more straightforward to take a stored localtimeTZ, and then calculate an up-to-date UTC time at runtime, and then derive a countdown timer from that. The key insight is that the best time to use UTC is when the users need that timer at runtime -- and not when they store the row in the db.

deleted 8y ago
[deleted]

falcolas 8y ago

> We should store the actual time of an event and update it when the scheduled time changes. I would love to see some (simple) code which will send a single alert to me at 1:30 am and another at 2:30am. My client registered me as MST (-7) when I set these two alarms in Feburary. Of particular note for corner cases: Nov 4th and Mar 10, 2019. The "scheduled time" will change, for many locations, twice yearly. EDIT: For added fun, instead consider the registration date as May 10th with the same timezone.