A lot of the time it's not really a matter of how well or badly the code has been written. It's more that an app hasn't been deployed in a long time and the infrastructure has changed, so now you have to update the deploy process. Or that the people who worked on it have moved on and now there's no understanding of the functionality, or documentation, so running a QA check is hard. Or that the test suite has broken so you need to fix that first. Or even that you don't know which systems rely on dates so you have to audit everything.
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.
If that's the case then let this be a wake-up call because there will be a time when you need to update your application in less than a week (see log4j for an example).
On 2022-08-15, IANA released their third zoneinfo database of 2022. On 2022-03-15, the IANA timezone database changed for the state of Palestine as they decided to move from DST a day later after going to DST a day earlier in 2021-10-29, which was also announced just over a week before the change.
If this is the third time this year your company has been in panic mode because of sudden timezone changes, you should really be changing your processes. Timezone databases change multiple times a year!
This time there was a good reason for postponing the switch. Originally it would have been the same day of the constitutional referendum. It was a good call to remove one potential factor of chaos from that day.
Having to deal with online calendars being off by one hour for a week is not that bad in comparison, we are already used to that :)
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).
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.
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.
Not all, or most, software that deals with time can be updated and deployed with less than 30 days notice. This is simply a grotesquely impractical policy change.
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.