I don't want to abolish time zones, I just want all the servers to run on UTC and all the apps to use standardized date/time libraries. Is that too much to ask?
As a web dev, I've spent more time and effort debugging datetime issues (across the frontend, backend, databases, and customer implementations) than all other classes of bugs put together. It feels like every year there are many days/weeks spent looking for these these, fixing them individually, and fixing them again at the meta level to account for the different ways people tried to fix them individually :(
The most enduring fix is almost always like you said, store timestamps in UTC (plus a zone name string separately, because an offset isn't always enough), plus use standard libs instead of trying to do your own datetime or time zone math, then format timestamps into human readable localized dates as late as possible for the user. In JS that means Luxon or date-fns instead of the woefully inadequate built-in Date methods.
For whoever uses PostgreSQL and needs to see this:
1. Please, please use native datetime objects instead of integers. A bigint (needed to represent datetimes past 2038) is 8 bytes, same as `timestamp`.
2. Please, please store explicit timezone values. Even if they're all UTC and it "feels redundant". `timestamptz` and `timestamp` are both 8 bytes in Postgres.
If you can't articulate the 10x advantage an integer gives you for your particular app (they are vanishingly few in 2024), please, please use `timestamptz`.
I did this at work - all cloud servers are at UTC at all time!
(The fact that we have offices in multiple timezones helped to motivate it).
This worked out pretty great IMHO, although I sometimes still have to convert the local timestamps for interaction of systems like Slack.
> I don't want to abolish time zones, I just want all the servers to run on UTC and all the apps to use standardized date/time libraries. Is that too much to ask?
Err, maybe you come from Windows?
In all variants of 'nix I'm aware of (and we are going back to the 1980's here), the kernel time is always UTC. You then set your TZ environment variable to reflect whatever timezone you are in.
Why? Well because back in the day we had time sharing as computers were far, far too expensive to be used by just one person. So from day 1 'nix assumed people would be logging in remotely, and when they did "date" had to display the correct time. In fact all time stamps were stored in UTC - including in the inode (eg, file modification times) and of course archive programs like tar used UTC exclusively.
Time moved on, we got PC's, and so the model moved to being one Computer was devoted exclusively for the use of one Person. DOS, and later Windows hark from that era and not surprisingly they too the opportunity to ditch all that UTC conversion complexity and store everything in local time.
But in a bizarre turn of events as computers got even cheaper they became so powerful they could services 100's or 1000's of people at one time, and with the rise of the internet it became cheap to connect them to those people. What's more it became profitable, as mum and dad just didn't want to handle the complexity of managing their own computer systems. Instead they pay someone else to do it. Fair enough I guess, but boggles my mind when youngsters here who evidently class themselves themselves as "computer professionals" say it's far too difficult to maintain computer hardware and systems, it should be left to the experts like AWS and Azure (at 10 fold mark up, thank you very much).
And so here we are, what was old is new again, and you are asking "please can we just store everything in UTC" because everyone shares computers.
Well, we did son. Then you young'ins came along and fucked it up.
Yes, the answer is yes, it is.