Thread by @mattjohnsonpint

A few people have asked me what software engineers should know about the #DaylightSavingTime bill (S.623) that just passed the US Senate. Here are my thoughts and guidance... 🧵

1) Don't panic, you have some time to deal with this. Nothing changes until the corresponding House bill (H.R.69) passes and it's signed into law by the President. Even then, nothing changes until the effective date stated in the law.

2) Though not yet in the text of the bill, Senator Rubio said on the Senate floor that it would be delayed until November of 2023. The final text of the law should confirm this.

In effect, this means that the fall-back transition scheduled for 2023-11-05 will be cancelled. When the clocks spring-forward on 2023-03-12, that will be the last time they need to change (unless the law is modified again).

However, if the law is made effective the date it is signed, that would be a problem. There's just not enough time to implement and distribute the changes. This has played out before in other parts of the world, with disastrous effects.
See my blog post: codeofmatt.com/on-the-timing-…

3) Note that this bill completely overrides all of the state-level laws that have recently passed in FL, CA, WA, and other places. It doesn't authorize each state to choose whether to switch or not. The only provision is that locations that presently don't use DST can stay there.

That means Arizona and Hawaii have a one-time choice to switch to DST, but IMHO that is not likely. The same goes for all of the US territories, since none use DST presently.

This puts Arizona in an interesting position with regard to the name of its time zone. By law it will still be in the Mountain time zone, but it will now align with Pacific time year-round. Expect some debate and clarifying laws over the next several years.

4) Again, don't panic. All modern operating systems and most programming environments now have facilities for dealing with time zones that are compatible with these types of changes. Chances are you will be fine. Just stay on top of updates!

5) Let's be a bit more specific about how things work. First, time zone changes are discussed and coordinated first on the IANA "TZ" mailing list. There's already an active thread there on this potential change.
iana.org/time-zones

The official data repository is published as a tarball on the IANA web site, but there's also an unofficial working copy on GitHub held by the current TZ Coordinator, Paul Eggert.
github.com/eggert/tz

At some point after (if) this law is passed, a new version of tzdata will be published. The current version is 2021e. The next version will be 2022a, etc.

Operating system vendors will pick up this data and release updates for their products through various mechanisms.

For Linux, the package to update is usually called "tzdata". For example, on Ubuntu it's "apt-get install tzdata".
packages.ubuntu.com/search?keyword…

For macOS, iOS, and Android, the tzdata from IANA is incorporated into the system software update process. Windows is a bit more complex, but ultimately time zone data is also delivered through updates. So the main point is to stay on top of updates!

A brief detour to talk about Windows. Since WinNT, Microsoft has maintained its own set of time zone data. It's stored in the Windows registry and is independent from IANA. You can read the official policy on this data here:
aka.ms/time

It also includes *two* copies of data that originates from IANA. One was introduced with Windows 8 for WinRT and now lives with UWP. The other comes from newer APIs that use data distributed from ICU. As you can imagine, it's important that these copies all stay in sync!

And thus, in true collaborative spirit, the team at Microsoft does pay attention to the IANA TZ discussion list, and participate when appropriate. The result is that changes proposed at IANA also get their own Windows updates, posted on this blog: techcommunity.microsoft.com/t5/daylight-sa…

6) Operating systems aren't the only place the data flows to. Many programming libraries carry their own copies of IANA tzdata - usually processed into some custom format. I mentioned ICU earlier, that's the International Components for Unicode project. unicode-org.github.io/icu/userguide/…

ICU is built for C/C++ and Java, and is used all over the place. Some programming languages (like .NET on Linux and macOS) depend on ICU for their time zone data. .NET on Windows still uses the Windows legacy time zone data presently.

But perhaps you are a .NET developer using the Noda Time library? In that case, you'll want to stay on top of Noda Time updates. nodatime.org

Or maybe you're a Python developer? Python 3.9+ has ZoneInfo, which uses either the OS's tzdata or a tzdata package from pypi.
docs.python.org/3/library/zone…

Or you might still be using pytz or dateutil? They each have their own time zone data embedded. Just stay on top of the current version and you'll be fine. The same goes for just about every other time zone library in every language out there.

6) But what if you've hard-coded your time zone rules? Does "PST" unequivocally mean "UTC-8" in your application? If so, you may be in for some pain - especially if you wait until this law goes into effect to deal with it.

Instead of hardcoding, use the feature of your language or a library. Don't confuse an offset such as UTC-8 for a time zone. Identify time zones by their IANA names, such as "America/Los_Angeles".

7) That's all for now. Reply or DM if you need specific help. 😀

I don't have a SoundCloud, but actually DST changes aren't all that important in the grand scheme of things. #IStandWithUkriane 🇺🇦

UPDATE! The final version of the text was that passed the Senate was amended to include an effective date of November 5, 2023. This is great, as it gives us developers time to implement, test, and distribute the changes. 😀👍🎉
congress.gov/bill/117th-con…

https://twitter.com/mattjohnsonpint/status/1504149032842657792?s=20&t=BB1JuJqB_mK14SXFMHIkLQ