Some call it "chaos", others might call it "badly written software".
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.
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!
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 :)
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).
* 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.
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.