Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>", you should instead store time in UTC everywhere

It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1])

Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal Time Code doesn't apply to governments changing DST and Time Zone rules in the future.

Pure UTC doesn't have enough metadata to encode future unknowns. For correct handling with zero loss of data, one must store the user's intended "wall-clock" time in his local TZ in the db.

There's irreducible complexity when dealing with user-specified appointment times so an uncompromising fixation on programming a "simple" implementation with pure UTC-on-dbserver and localtime-at-only-at-browser-Javascript ... will lead to a broken calendaring program.

[1] https://news.ycombinator.com/item?id=10990240

You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

> But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

Congratulation, your emotional refusal to deal with zoned datetimes has led you to a non-standard ad-hoc reinvention of timezones, your misguided quest for simplicity and obstinate rejection of reality has thus led you to a system which is definitely more complex, probably less correct and likely less performant than if you'd just done the right thing in the first place.

>a simple way, [...] and running a script to update future dates

I've commented previously that it's not a good idea to change the rows of UTC times in the database.[1]

Designing "system correctness" to depend on on the reliability of a correctly written SQL statements completing atomic transactions for millions of rows is not a good idea. In addition to batch db updates of UTC being extremely fragile, it's also not simple.

(It's fascinating to note that the multiple programmers independently arrive at the approach to update database rows of UTC times. There's something about it that's cognitively satisfying that attracts repeated reinvention.)

[1] https://news.ycombinator.com/item?id=10991894

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.

>, 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.

> 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.

>You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

Seriously? That, in your opinion, is simpler?

Reply on news.ycombinator.com