Which production-ready datetime library doesn't use zoneinfo? There should be no need to patch otherwise there would be quite a lot of patching happening each year. The current version is 2021e, meaning it's the 5th iteration for 2021.

Notably Fiji decided to not use DST in 2021/2022 but apparently plans to resume using it afterwards.

Any software using an IANA zone (e.g., America/New_York) shouldn't have any trouble. But any software that uses zone labels like EST might do the wrong thing, since EDT is being renamed to EST but will still have EDT's offset.

Honestly.... California already approved a measure to do this (there are a bunch more steps to make it actually happen). So, this is WAY better than if WA/OR were an hour apart from CA for half the year. Also, Seattle/Portland (etc) would suddenly not be America/Los_Angeles timezone anymore.

WA and OR already did permanent daylight savings time, same as CA. All 3 states were just waiting for the federal government to allow them to change.

This is incorrect. Not sure where you get your news.

I was wrong about California, looks like the voters approved allowing the legislature to vote on going to daylight savings time permanently, but the CA legislature has not done so:

https://en.wikipedia.org/wiki/2018_California_Proposition_7

WA has enacted it, pending federal government approval:

https://app.leg.wa.gov/RCW/default.aspx?cite=1.20.052

Looks like Oregon’s is contingent on California enacting it, but it is a passed law:

https://olis.oregonlegislature.gov/liz/2019R1/Downloads/Meas...

https://www.opb.org/article/2021/11/06/oregon-wants-to-stop-...

Oh, we've changed them so many times at this point. In the 2000s we changed the dates that we move the clocks back and forth.

This is probably just a configuration update.

>probably just a configuration update.

famous last words

The zoneinfo files describe the rules, past, present and future

True but hopefully this would be "the last time" in the US for this sort of thing.