[jeroenhd]

This is why I dislike custom "we'll-do-it-ourselves" solutions. Updating your operating system's tz-database is easy; it's normally a single package with no dependencies that you can install without patching the rest of your outdated operating system full of security holes if you're in an "enterprise" environment where normal updates are seemingly impossible.

If you need to rebuild your application or even your Docker container (just bind-mount it in place and update the host, all applications fixed in one go!) then IMO you're bringing this kind of crap on yourself.

At most you should be reloading/restarting your application to apply the new timezone database, which shouldn't cause a problem if you've set up the right fallback and scaling systems to deliver whatever SLA you've promised to customers.

My shitty PHP frontends I built when I finished high school can update and reload the timezone database in less than a second through `systemctl restart php8.1-fpm`. If you need a month to update the timezone database, maybe you should've written whatever you made in shitty PHP just like me, because apparently shitty PHP is more foolproof in handling common occurrences like timezone changes than Enterprise Grade (TM) Cloud (R) Applications (C).

[aeyes]

Your post is completely missing the point. Here are some examples of what I have seen go wrong:

* Microsoft didn't release an update, all Windows machines had incorrect time.

* Google Calender never got the update, it was wrong for a week. Shifting everything by one hour in your head isn't too bad but for some reason meetings scheduled by people in other timezones weren't off by an hour.

* Slack never got the update

* Managed databases running on cloud providers didn't get the update.

* A default Postgres installation will run with the tzdata shipped with Postgres, the next release is 1-2 months away. Some distros probably use the OS tzdata instead and you could recompile to fix this.

* Software using temporary credentials and MFA systems broke because timestamps mismatched.

Unless you run your whole company on homegrown code you would surely feel some pain if something like this happened in your country.

[jeroenhd]

I'm sure I would, because many services I use daily are in fact written badly. I don't exactly expect much from tech giants like Microsoft and Google as they get localisation and feature detection wrong all the time if you're not living in the USA. As for Slack, I'm glad I use that minimally.

Managed databases not getting the patch are badly managed. Postgres deciding to do its own thing because it thinks it knows better is a bad decision if it doesn't know better. They've decided, probably for good reason, that the OS zoneinfo wasn't good enough, but that places the burden of maintaining zoneinfo files on them.

Temporary credentials and MFA should not be timezone dependent at all, if the difference in timezones between client and server are a problem then the software hasn't been designed right.

I'm not saying nobody will notice timezone changes and the bugs they cause; of course people do, because commonly used software tends to be written badly. That doesn't mean the responsibility of fixing this crap doesn't fall on the people writing software.

The real world moves fast sometimes and timezones are complicated; to fix that, either rely on someone else who's maintaining this stuff for you (distro packagers etc.) or take responsibility for your own solution. My shitty PHP code deals with the timezone change without issue by restarting the daemon process every other day at a random point in time; the fact these billion dollar tech giants can't work out a solution is a symptom of a much bigger problem to me. The FAANG people earning ridiculous amounts of money each month should be smart enough to figure out how do deploy a zonefile update in a day or two.