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

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