The 'prior art' is not y2k but rather the DST change in 2006 (to our current weekends in North America).
That was when they restructured most of their timezone information into easily updated files that made the operating system generally adapt pretty quickly, along with client-side software for anything *newly* generated in scheduling software.
However, the issues here are what to do about already-existing scheduled events - how do they adapt depends on what your internal model is for storing "where" they are (which timezone they're meant to follow). If you didn't separate out America/Vancouver in your system because it was always the same as America/Los_Angeles...it is an almost unfixable problem because you have no way to isolate what is and isn't in "Canada".
So this is why I've been saying, for months now since it was announced, that it was going to be a mess because there wasn't enough time to develop and test the solutions in the middle of all of the other work that app teams are doing (often with reduced resources due to the layoffs of the last 3 years) before everything went live. You really want this stuff tested AT LEAST 6 months before the first change, preferably a full year.
I can't imagine the scheduling disasters for anybody actually using Egypt time over the last 15 years, when they ditched DST, *partially* brought it back (the day would change based on Ramadan) and then in March of '23 announced that in April of '23 they would go back to switching. Pretty sure anybody of any import just set their clocks collectively to something from Europe for the stability.