It amazes me how governments—repeatedly—make last-minute changes to DST and then are shocked, just shocked, about the tech turmoil that inevitably ensues. Brazil in 2019 stopped using DST with only 6 months' notice, and that was still a mess. Countries really should be giving 2-3 years' heads up to allow updating all the software that was playing by the old time zone rules. IoT and mobile devices are particularly challenging because they often require OS or firmware updates to get new time zone rules, and many device vendors' support budgets are skimpy.

FWIW, Temporal.ZonedDateTime's default behavior was designed to flag cases when parsing previously-stored data after time zone rules have unexpectedly changed. So a string like 2020-01-15T12:00:00-02:00[America/Sao_Paulo] stores both the exact timestamp (what you'd store in a Temporal.Instant) as well as the time zone identifier America/Sao_Paulo. If you try to parse that string today (after we know about Brazil's stopping DST in 2019) using Temporal.ZonedDateTime.from then you'll get a RangeError because there's a conflict between the offset -02:00 and the time zone ID America/Sao_Paulo.

For developers who know what behavior they want in cases like that, there's an offset option that can be used to choose how to resolve conflicts. https://tc39.es/proposal-temporal/docs/zoneddatetime.html#from https://tc39.es/proposal-temporal/docs/ambiguity.html#examples-offset-option

This won't help cases like Lebanon's which have minimal (or negative!) advance notice, but should help developers find and recover from changes like Brazil's where changes are announced a few months in advance: long enough for IANA Time Zone Database updates to be rolled out into ECMAScript implementations.

Thank you for coming to my TED talk. ⏰