themildtake
Analysis William Dunn ·

Off by an hour and no errors were raised

The Sunshine Protection Act passed the House on 14 July 2026 by 308 to 117. It does not leave the clock on the summer setting; it redefines what standard time means, turning the string EST from UTC-5 into UTC-4 and Guam from UTC+10 into UTC+11. That distinction is the whole story, because the offset is not stored in one place. It is copied into the IANA database, into every operating system, into a dozen language runtimes that each ship their own copy, into vendored data files inside applications, and into firmware that will never be updated again. The last time Congress moved daylight time it cost somewhere between $350 million and a billion dollars to patch, and that change was easier than this one. This is how the change actually reaches your code, why the broken data will still validate, and what it costs.

  • daylight-saving-time
  • time-zones
  • software-infrastructure
  • legislation
  • data-integrity

On 14 July 2026 the House of Representatives passed H.R. 139, the Sunshine Protection Act, by 308 to 117.

The operative part is two sentences. Section 2(a) repeals section 3 of the Uniform Time Act of 1966, the provision that creates daylight saving time as a temporary annual period. Section 2(b) then amends 15 U.S.C. § 261, the 1918 statute that defines the nine United States time zones, by striking each zone's offset and substituting the next one over. "5 hours" behind Greenwich becomes "4 hours." "8 hours" becomes "7 hours." The ninth zone, Chamorro, is the only one measured ahead of Greenwich, so there the substitution runs the other way, and "10 hours" ahead becomes "11 hours."

That is what "permanent daylight saving time" means in law. The country does not keep observing daylight time forever. Daylight time is abolished, and standard time is redefined to be the thing daylight time used to be. Eastern goes from UTC-5 to UTC-4. Pacific from UTC-8 to UTC-7. Guam, which has never observed daylight saving in its life, moves from UTC+10 to UTC+11 because the statute renumbers its zone along with the rest.

The clocks on the wall barely notice; in most of the country they simply never fall back next November. The software notices, because software does not store "the time on the wall." It stores an offset, and the bill changes what the offset is.

The offset is not in one place, it is in a dozen

There is a common mental model where "the time zones" live in one authoritative file and everything reads from it. That model is wrong, and the ways it is wrong are the entire cost of this bill.

The upstream source of truth is the IANA time zone database, tzdb, the thing every serious system ultimately derives from. It ships between three and twenty-one releases a year, mostly because some government somewhere changed the rules. In tzdb the eastern zone is a single line. It sets the offset to -5:00, applies the US daylight rules, and formats the abbreviation as E%sT so the middle letter fills in as S or D by season. After enactment that line becomes offset -4:00, no rules, fixed abbreviation. One edit, upstream.

Then it has to travel, and it does not travel as one thing to one place. It travels as a dozen independent copies, each on its own schedule:

  • The operating system carries its own compiled copy. On Linux that is the tzdata package you get from apt or yum. On Windows it is a registry format Microsoft maintains separately from IANA, updated through Windows Update, historically lagging IANA releases and occasionally disagreeing with them outright. macOS ships its own, updated with the OS.
  • The language runtimes ship their own, independent of the OS. Java bundles tzdata inside the JDK; patching the host does nothing for it, and you need a JDK update or the tzupdater tool, with enterprise JREs historically months behind an IANA release. Go embeds a copy at build time unless you set ZONEINFO. Node.js carries tz data inside its bundled ICU. .NET reads the OS on Windows and ICU everywhere else. Python's zoneinfo uses the system copy if present and falls back to a first-party tzdata package from PyPI, while a great deal of older code still pins pytz at whatever version was current when it was written.
  • The application ships its own on top of that. moment-timezone bundles a data file baked into your JavaScript bundle. PHP updates through a separate timezonedb package. Ruby's TZInfo can carry its own gem data. Each of these is a copy of the copy.

A single server can therefore hold four different answers to "what is EST" at once, the one in the OS, the one inside its JVM, the one inside a vendored npm data file, and the one a developer hardcoded three years ago because the rules had not changed since 2007 and it seemed safe. When the offset was stable, all four agreed and nobody had to know they were separate. The bill's redefinition is the event that pulls them apart, and every layer has to be found and updated on its own before they agree again.

And the abbreviation has no clean answer at all. The tz maintainers have been arguing this since before the vote. Keep EST and it is legally correct and contradicts forty years of stored data and printed schedules. Emit EDT year round and it names a daylight saving time that no longer legally exists. Emit ET and it is honest and is not a three-letter code, which is what a lot of parsing expects. Paul Eggert's summary, on the list, is that whatever they do here is going to be a mess. There is no fourth option, because the database has to encode a fact about the world and the fact is that a word changed meaning.

The operational steps for finding and fixing each of these patterns in a codebase, and wiring the checks into CI, are collected in the runbooks below.

Two of the most-used date libraries fail this in opposite ways

One layer down, in the JavaScript date library, the split-copy problem shows up in miniature. The two most-used options handle zone data on opposite principles. moment-timezone bundles its own compiled copy of the IANA data straight into your application bundle; if you do not upgrade the package, your app keeps the old offsets no matter how current the machine underneath it is. Luxon, the library positioned as its successor, does the reverse. It "abus[es] built-in Intl APIs" and inherits whatever zone data the host's ICU happens to carry, so it cannot be pinned, and two clients on different browser or Node versions compute different offsets for the same zone. Luxon's own tracker documents arithmetic across a DST boundary returning different results depending on the client machine. One library ships a copy that silently goes stale; the other inherits a copy it cannot control. Both are wrong in a different direction the moment the rules move.

And moment is officially legacy (its maintainers put it in maintenance mode and steer new projects elsewhere), yet it remains embedded in an enormous amount of shipping software, so the stale-bundled-data failure is both widespread and largely unowned.

The dress rehearsal is already on the record. In issue #1141 someone asked moment-timezone to encode British Columbia's permanent switch and immediately hit the abbreviation question, call it PT or keep emitting PST/PDT for an offset that no longer alternates, and the ticket sat without a maintainer resolution. That is the Canadian change, one province and one zone. H.R. 139 is the same unresolved question multiplied across every US zone and 340 million people, aimed at a library layer that could not settle it for one.

The failure mode is data that still validates

Software that crashes gets fixed. The expensive category is software that keeps running and quietly returns a different answer than it did last week.

The most common pattern in the world is a Postgres timestamptz column, which does not store a time zone. It stores a UTC instant, and the session zone is used to convert in and out. Insert a January 2027 appointment today for 10:00 in America/New_York, and the database resolves it to 15:00 UTC using the tzdata installed at that moment. Update tzdata after enactment and the same row reads back as 11:00 local. The row did not change. The bytes did not change. The function used to interpret them did, and no constraint, checksum, or type error will notice.

Crunchy Data worked this exact case through in March. Their fix is to stop storing the answer, and instead keep the wall-clock value the user typed, keep the IANA identifier next to it, and keep the UTC instant as a derived column a trigger recomputes when the rules move. That is the correct architecture and almost nobody has it, because for thirty years the single timestamptz column has been the advice everyone gives.

The same shape recurs everywhere a future local time is resolved to an instant too early:

  • iCalendar. An .ics file can carry its own VTIMEZONE block with the offsets baked in. Files exported before the change, and recurring series pinned to them, keep the old arithmetic no matter how current the client's data is.
  • cron and schedulers. A job set to a specific local hour, tuned against a UTC-facing downstream, now fires an hour off relative to it for the four months of the year that used to be winter.
  • Stored abbreviations. Anything that saved "EST" as a string rather than an offset or an identifier now holds a token that means two different things depending on when it was written, with nothing in the record to say which. That is a live problem for financial trade timestamps, clinical records, and audit logs, where the whole point is that the time is legally authoritative.

None of these throws. They produce a value off by exactly 3,600 seconds, in a field that has always been allowed to hold that value.

The security layer fails the other way, loud and closed

The data layer's failure is quiet. It accepts an hour that is wrong and still in range. The security layer is engineered to do the exact opposite. To an authentication protocol a clock that disagrees with its peers is indistinguishable from a replay attack or a forged validity window, so the protocols treat disagreement as hostile and refuse.

Kerberos is the clearest case. It stamps every ticket in UTC and rejects any request whose clock sits more than five minutes from the key server's, a tolerance kept deliberately tight to close the replay window. An hour is not a near miss; it is twelve times the entire budget. A machine an hour off cannot authenticate at all, returning KRB_AP_ERR_SKEW, clock skew too great. In a Windows domain where Microsoft's timezone update has reached some machines and not others (Microsoft ships its own zone data on its own cadence, distinct from IANA), the domain controller and its clients now disagree by an hour, and logins across the domain fail together.

The guardrail matters, because this is easy to overstate. None of these protocols care about your time zone. Kerberos tickets, TLS notBefore/notAfter, JWT exp and nbf, TOTP codes, and DNSSEC signature windows are all expressed in UTC, and the redefinition does not move UTC. They break only when a machine computes the wrong UTC, and that is exactly what this change manufactures at scale. Any system that reaches UTC by taking local time and applying an offset, while holding a stale copy of that offset, now derives the wrong UTC. Windows is built that way, hardware clock in local time and UTC derived from its own DST rules, which is the precise recipe for a domain to skew the moment the rules and the law disagree.

Downstream of a wrong UTC, everything time-bound trips at once. A TLS certificate reads as "not yet valid" when the clock is behind and "expired" when it is ahead, on a certificate that is neither. A TOTP code misses its thirty-second window. The specification says this cannot happen because TOTP runs on UTC, and yet users have been locked out on time-change nights anyway, because a device derived its UTC wrong. A fifteen-minute JWT is rejected as expired the instant it is issued, or, quieter and worse, a service running an hour slow honours a token an hour past its expiry, reopening a replay window that was meant to be shut.

That is the cascade. The offset lives in a dozen independent copies, so during the propagation window two machines on the same request path can hold different offsets and therefore different UTCs. The data layer tolerates the disagreement and writes a wrong-but-valid row. The security layer does not tolerate it and fails closed. Because authentication sits upstream of everything, one stale relay does not corrupt a single record; it denies the whole chain behind the login. Clustered at a transition, intermittent, and pointed at the clock rather than the code, it is about the hardest class of outage there is to diagnose.

British Columbia already ran this experiment

This is not hypothetical, because a jurisdiction of five and a half million people did a version of it in March.

British Columbia sprang forward on 8 March 2026 and legislated that it will not fall back, moving to permanent UTC-7, announced eight months before the divergence actually bites this November. As of early March the IANA database still had America/Vancouver falling back in the autumn; the corrected rules landed in a spring release. Four weeks of gap, on a change that was publicly legislated, with a named date, in a jurisdiction the maintainers were watching.

That gap is the point. The IANA release is the start of the propagation, not the end. Downstream sits every distribution's package, every container image built before the release, every Android device on a vendor's own cadence, every appliance whose last firmware shipped in 2019.

The prior art is not encouraging. Yukon went permanent in 2020 and it went smoothly, for 45,000 people. Samoa crossed the date line in 2011 and payroll systems booked negative hours worked. Turkey moved permanently to UTC+3 in 2016 with about three weeks' notice and appointment systems sent people to clinics at the wrong hour. British Columbia is an order of magnitude larger than any of them, and the United States is two orders larger than British Columbia. And BC's change was the easy kind, a rules change where the clock stops moving but no offset was renamed by statute. H.R. 139 is the hard kind, applied to 340 million people.

The change is global, whether the rest of the world wants it or not

The question of foreign compliance rests on a wrong assumption, that each country decides for itself whether to take the change. The tz database does not work that way. It is a single upstream source that virtually every operating system, language runtime, and web service on earth derives from, and the US zones sit in it next to everyone else's. When America/New_York is redefined, the edit ships in the same global tzdata release a German bank, a Japanese airline, and an Australian SaaS vendor all pull on their next update. A European server running America/New_York, which is any server the moment its application represents a US time, gets the new offset automatically. There is no opt-in. The only choice a foreign operator has is how quickly to update, and the cost of not updating is not sovereignty; it is showing the wrong US time. The display layer travels the same road. The US zone names in Unicode CLDR, and the locale data Apple, Google, and IBM ship inside ICU, would change in every language, so the new meaning of EST renders in French, German, and Japanese too.

What foreign governments will not do is move their own clocks to match. The European Union already tried to abolish its own switch. Parliament voted in 2019 to end seasonal changes by 2021, and the measure has sat in the Council ever since, so Europe still springs forward and falls back. The US going permanent while the EU keeps switching produces more distinct offset relationships across the year, not fewer. The New York to London gap is five hours for most of the year today, dropping to four only for the couple of weeks each spring and autumn when the two sides transition on different dates; with the US frozen on its summer offset and Europe still switching, that gap becomes four hours for the whole of the northern winter, returns to five only in summer, and the brief misalignment windows move to new dates. Every system that schedules across the Atlantic re-encodes that relationship, and the tz data resolves the instant correctly once it is updated; the human schedules, the printed timetables, and the offset a developer wrote into a config three years ago do not.

Finance keeps its clock in New York, so this moves its clock

The one domain that never fully took the "just store UTC" advice is the one with the most at stake here, and for a defensible reason. Global finance is organised around New York. The reference events are the opening and closing bells of the NYSE and Nasdaq, defined in Eastern wall-clock time at 9:30 and 16:00, and much of the machinery records in Eastern to match. The FIX protocol carries its wire timestamps in UTC, but its LocalMktDate field, the trade date on venues like the NYSE Pillar gateway, is Eastern local date, not UTC. Session boundaries, trade dates, and a long tail of reconciliation, surveillance, and backtesting systems key off Eastern Time precisely because that is when the dominant market is open.

So the bill does not change a zone finance merely consumes; it redefines the clock finance keeps its own books in. A system that used the America/New_York zone moves with the market, both tracking the same wall clock, and absorbs the change as long as its tz data is current. A system that treated EST as a fixed UTC-5, the common shortcut taken exactly because the offset had not moved since 2007, now sits an hour off the real Eastern wall clock for every month that used to be winter. And any record literally stamped with the string EST turns ambiguous across the boundary. Before enactment EST means UTC-5, and after it means UTC-4, so one historical series carries three letters that denote two different instants, which is the sort of thing trade reconstruction, regulatory reporting, and backtesting cannot absorb.

The regulation does not rescue you, because it lives on the far side of the same seam. MiFID II's RTS 25 requires reportable events to be timestamped with traceability to UTC, to 100 microseconds for the fastest venues, and that UTC audit clock keeps ticking correctly straight through the change. What moves underneath it is the Eastern session it is recording. A 9:30 open that resolved to 14:30 UTC through the winter now resolves to 13:30, so every correlation between the New-York-anchored session and a UTC-native feed, a crypto venue, a London or Tokyo book, or the audit trail itself, shifts by an hour for the formerly-winter months. UTC traceability guarantees the audit clock is right. It does nothing about the fact that the session being audited was defined in a word Congress just re-pointed.

NTP is the escape hatch, so the trapped systems are the ones that matter

There is one layer the redefinition genuinely cannot touch, and naming it sharpens the rest. NTP, the protocol that keeps the world's clocks synchronised, distributes pure UTC, with no zones, no daylight rules, and no notion of "standard time" at all. Applying an offset to get local time is the operating system's job, layered on top. A machine that takes its authoritative time from NTP and treats local time as display only holds the correct instant no matter what Congress does to the word; its UTC does not move.

That is the escape hatch, and it inverts the risk map. The exposed systems are exactly the ones that cannot use it, the air-gapped networks with no time source but their own oscillator, the embedded devices running off a battery-backed clock they were set to once, and anything that treats local wall-time as authoritative and reconstructs UTC from a stale offset, which is Windows again, keeping its hardware clock in local time.

Hardware security modules are the sharp end of that list. An HSM runs FIPS-validated firmware, and because older firmware stays validated while a new load can trigger re-validation, operators are actively discouraged from patching, and many sit air-gapped with their own internal clock. RFC 3161 timestamping authorities sign trusted timestamps with exactly these devices, the evidence relied on for code signing, legal filings, and digital forensics. A timestamping authority running an hour off does not throw an error. It issues cryptographically vouched-for timestamps that are confidently, verifiably an hour wrong, which is worse than an obvious failure, because the signature is an instruction to believe the time. These are the legacy devices a one-line change to a federal offset reaches, and a tzdata package update does not.

What the last one cost, and why this one costs more

Software has a lineage of dated migrations, and their costs are the only real basis for guessing at this one. The one everyone remembers is Y2K. The US Commerce Department put domestic remediation at $100 billion across 1995 to 2001, and worldwide estimates ran to $300 billion and up. Y2K is remembered as an anticlimax precisely because it was expensive, with years of runway against a fixed, non-negotiable deadline, spent finding two-digit years before they rolled to 1900. It also had a mercy this change does not. Its failure was loud. A date that flips to 1900 is obviously wrong and stops a program cold, so the bugs announced themselves. The same is true of the 2038 problem still ahead of us, when 32-bit Unix timestamps overflow, a hard, visible, testable boundary you can point a scanner at.

The 2005 daylight-saving change was the closest analog to this one, and it is the more useful comparison because it is smaller and quieter than Y2K. The Energy Policy Act of 2005 moved daylight time three weeks earlier in spring and a week later in fall. It was signed in August 2005 and took effect in March 2007 (nineteen months of notice), and it was still expensive. The patching alone ran around $350 million, with broader estimates of the full remediation reaching $500 million to a billion dollars. The Air Transport Association put the airlines' share of the schedule desync at $147 million for 2007 alone. IT departments spent that season calling it a mini-Y2K.

That was the easy change, and it had the vocabulary in its favour. In 2005 America/New_York still meant "UTC-5 in winter, UTC-4 in summer." Only the boundary between the two moved. Every stored offset, every abbreviation, every hardcoded constant stayed exactly as true as it had been. The rules file changed; the words did not.

H.R. 139 changes the words. It touches every one of the copies in the supply chain above, not just the transition dates inside them, and it does so with far less lead time than nineteen months, because the bill as passed carries no effective date at all, so the working assumption is enactment. A harder change with less notice does not come in under the last one's bill.

And the patching is the visible part, the part that gets budgeted. The real cost is the tail, the systems nobody patches in time, each emitting a value an hour wrong into billing, payroll, overtime calculations, SLA timers, and settlement timestamps, silently, because every one of those numbers is still inside its allowed range. Economist William Shughart has estimated the country loses about $1.7 billion a year just to the friction of changing clocks twice a year. The one-time cost of changing what the clocks mean is a different and larger number, and most of it lands not as an invoice but as a year of quietly wrong data.

The policy's own case rests on a few claimed benefits, each with its evidence. The energy argument that justified daylight saving in the first place cuts both ways, with the Department of Transportation measuring roughly a one percent reduction in the 1970s while a later natural experiment in Indiana found residential electricity use rising by about the same amount, as evening heating and cooling offset the lighting saved. The other arguments are about evening light, which lifts retail spending and is associated with fewer evening robberies and traffic deaths. Those findings come from studying the twice-a-year transition rather than a permanent regime, a distinction the sleep-medicine literature is explicit about, and permanent daylight time produces the brighter evening by darkening the winter morning, moving that darkness onto the commute and the school run. The recurring saving no one disputes is ending the switch itself; the open question is which permanent time to end it on.

Guam gets an offset almost nobody else has

Subsection (b)(1)(I) moves the ninth zone from ten hours ahead of UTC to eleven. Chamorro Standard Time covers Guam and the Northern Mariana Islands, neither of which has ever observed daylight saving, and UTC+11 currently belongs to the Solomon Islands, Vanuatu, New Caledonia, and part of Russia.

Guam's entire operational geometry is built on UTC+10, shared with Papua New Guinea, an hour ahead of Japan and the Philippines, and the basis for scheduling at Andersen Air Force Base and every airline connection through Antonio B. Won Pat International. The bill moves it by statute, and whether it has to move is genuinely unclear. The new subsection (b) lets a state or area "previously exempted" under the repealed section 3(a) keep its prior time, but it is not obvious Guam was ever exempted under 3(a) rather than simply never brought in. The same question has a cleaner answer for Arizona and Hawaii, which did formally exempt and whom the drafters plainly had in mind.

The states with no such history get no choice at all. That is the quiet inversion in the bill. Repealing section 3 removes the very mechanism a state uses today to sit on permanent standard time. Nineteen states hold trigger laws that fire on federal permission and would get exactly what they asked for. They are Alabama, Colorado, Delaware, Florida, Georgia, Idaho, Louisiana, Maine, Minnesota, Mississippi, Montana, Oklahoma, Oregon, South Carolina, Tennessee, Texas, Utah, Washington, and Wyoming. A state that would rather have permanent standard time would, after enactment, have no statutory route to it.

A bill written to be signed, not implemented

Nothing about the timing is about software. Permanent daylight time is a Trump priority. He posted in May that he would "work very hard" to see the Sunshine Protection Act signed and that it would be "a very nice WIN for the Republican Party," and the House delivered it as exactly that, a popular and low-cost victory bundled into a single rule with unrelated national-security appropriations and a veterans bill. Ending the clock change polls well, and voting for it in July costs a member nothing, months before anyone has to wake into a dark January. It is a messaging vote that happens to rewrite a statute. The durable lobby behind it is commercial rather than financial, the retail and convenience-store trade groups and chambers of commerce alongside the golf and recreation industries, all of which profit from the evening dividend of more after-work daylight for shopping, driving, and play. The narrower New-York-to-London gap is a side effect of that push rather than the aim of it, and there is no sign of a Wall Street campaign to shorten the transatlantic offset.

The barriers are where the substance is, and most of them are not technical. The sleep-medicine and medical associations back ending the switch but want permanent standard time, because morning light is what anchors the circadian clock; under H.R. 139 the sun rises after 9 a.m. in Indianapolis in mid-January, and Congress already ran this experiment in 1974 and repealed it inside ten months when winter mornings went dark. The industries that would have to absorb the change are asking for room. Airlines for America wants up to 24 months to re-cut schedules, crewing, and reservation systems, and every software vendor downstream of the tz database needs a comparable window. And the procedural wall is real. Tom Cotton, a Trump ally, blocked the bill by objection in 2025, says he will ask the majority leader not to floor it, and roughly a dozen Commerce Committee members of both parties have voted against permanent daylight time before; the majority leader himself calls it an issue people are "willing to really slow things down over". For now the likeliest outcome is the one every prior version reached, passage in one chamber and stall in the other.

That politics is not a digression from the software problem; it is the cause of it. A bill written to be signed as a win is a bill nobody has planned to implement, which is how it reached the floor redefining nine statutory offsets with no line saying when they change. Every serious prior version named a date. That one missing sentence is the whole distance between an orderly rollout and a redefinition tearing through the IANA database, every operating system, every runtime with its own embedded copy, every container, every vendored data file, every appliance with the old rules in flash, and every row where a future local time was resolved to UTC too early, with no error raised anywhere along the way. The vote was never really about the day the clocks change, which is exactly why it left that day blank.

Runbooks

Static scanners catch part of this and miss part of it. Ruff and Error Prone flag naive datetimes in Python and Java, nothing off the shelf flags a stored offset or an EST string, and no scanner sees stale tzdata, because that is a runtime version rather than a code pattern. Each runbook below names what it can hand to a tool and what stays manual.

Store UTC and a named zone

What breaks. Persisting a fixed offset, an EST string, or a UTC instant computed from a future local time freezes an assumption the rule change invalidates. Resolve a January 2027 appointment to UTC today and it reads back an hour off once the rules move, with no error raised.

Find it. In Python, turn on Ruff's flake8-datetimez rules to flag naive datetimes.

# pyproject.toml
[tool.ruff.lint]
select = ["DTZ"]   # DTZ001/005/007: naive datetime, now() without tz, strptime without zone

In Java, enable Error Prone's JavaTimeDefaultTimeZone, which flags LocalDateTime.now() and friends that silently take the system zone. Neither tool catches a stored offset or abbreviation, so add a Semgrep rule for that gap.

rules:
  - id: stored-tz-abbreviation-or-offset
    pattern-regex: '["\x27](E|C|M|P)[SD]T["\x27]|[+-]0[45]:00'
    message: Stored timezone abbreviation or fixed offset. Use an IANA id plus UTC.
    languages: [generic]
    severity: WARNING

Fix it. Store the UTC instant and the IANA zone id in separate columns and convert to local only at read time. For future events, keep the wall-clock value the user typed alongside the zone id, and hold the UTC instant as a derived column a trigger recomputes when tzdata moves.

Verify. Bump tzdata, recompute the derived column for future rows, and confirm each event still lands on the wall-clock time the user intended.

Automate in CI. Run Ruff DTZ and Error Prone as build errors, add the Semgrep rule to the SAST step, and add a migration check that new timestamp columns are timestamptz and carry a zone id.

Keep tzdata current everywhere

What breaks. Every layer caches a frozen tzdata snapshot and refreshes only on its own update. Patching the OS copy does nothing for the copy inside the JVM, a static Go binary, Node's ICU, a vendored moment-timezone, or an already-built container image, so any of those can compute post-change times an hour off while the host looks current.

Find it. Ask any system which transitions it believes in.

zdump -v America/New_York | grep 2027   # do the transitions match reality?

Then read each layer's version.

rpm -q tzdata            # or: apt list --installed tzdata      -> 2026a
java -jar tzupdater.jar -V                                       # JVM's own copy
node -e "console.log(process.versions.tz)"   # recent Node exposes its tz version
pip show tzdata          # the PyPI package zoneinfo falls back to

Fix it. Update each copy on its own path. apt-get install --only-upgrade tzdata or yum update tzdata for the OS. Upgrade the JDK (preferred) or run tzupdater -l for the JVM. Upgrade Node, or add full-icu, for the ICU copy. Rebuild a static Go binary with a newer toolchain, or copy /usr/share/zoneinfo into the image. pip install --upgrade tzdata for Python. Rebuild container images, since a running container never sees a host update.

Verify. Re-run zdump or process.versions.tz and confirm the target transition is now correct.

Automate in CI. Point Dependabot or Renovate at the tzdata package, the Node version, and the base images so bumps arrive as PRs. Add a test that fails the build when the runtime's tzdata is older than a known-good version, or that asserts a specific transition. Rebuild containers whenever the base image's tzdata moves.

Inventory devices that cannot be patched

What breaks. Thermostats, badge readers, security recorders, PLCs, and hardware security modules often burn the DST rules into firmware with no update path. At the old transition date they shift when the country does not, or fail to shift when it does, and sit an hour off silently. HSMs are the sharp end, because FIPS-validated firmware discourages patching and many run air-gapped on their own clock.

Find it. Extend the asset inventory to flag anything with an onboard clock and hardcoded DST that is not disciplined by NTP or fed from a central zone source. Pull the list from the CMDB and cross-check vendor firmware notes for how each model handles time zones.

Fix it. Prefer NTP-UTC with local time as display only wherever the device supports it. For devices that keep local time as the authoritative clock, apply vendor firmware if it exists, and otherwise schedule a documented manual correction at the transition. Treat HSM and timestamping-authority clocks as change-controlled, and coordinate any move with the vendor because of re-validation constraints.

Verify. Compare each device's reported time to an NTP-UTC reference across the transition window and alert on drift.

Automate in ops. Stand up monitoring that diffs device clocks against NTP rather than a CI job, tag these assets in change management, and set a recurring control at each transition so they surface every time.

Audit records anchored to New York time

What breaks. A great deal of finance keys to the Eastern trading day on purpose, with the bells at 9:30 and 16:00 and FIX LocalMktDate recorded as Eastern local date rather than UTC. Anything that stored EST or a fixed offset drifts from the real Eastern wall clock after the change, the mapping between Eastern and UTC shifts, and any correlation with a UTC-native feed or the audit trail moves an hour for the months that used to be winter. Historical EST strings that span the boundary denote two different instants.

Find it. Grep the code and the data for hardcoded Eastern offsets, abbreviations, and session-time constants, locate the systems that store trade dates and session boundaries, and list every join that correlates the US session against a crypto venue, a London or Tokyo book, or a regulatory timestamp.

Fix it. Move Eastern-anchored logic onto America/New_York rather than a fixed offset. Re-express stored abbreviations as UTC plus a zone id where the source allows, and for historical series that cross the boundary, record which regime each timestamp used so reconstruction stays unambiguous.

Verify. Compute a session boundary and a trade date across the change date and confirm they still resolve to the intended instant, then reconcile a sample of records against the UTC audit trail on both sides of the boundary.

Automate in CI. Add a Semgrep or grep rule for Eastern offset and abbreviation constants, and pin the session-boundary math against a fixture that spans the transition so a regression fails the build.

Test the boundary before it arrives

What breaks. Recurring jobs, payroll, billing, and reporting that resolve local time can miscompute at and after the change. Permanent daylight time removes the autumn fall-back, so anything that still expects a November shift computes the wrong hour for the whole of winter.

Find it. Enumerate the scheduled, recurring, billing, and reporting jobs keyed to local time, and fix the effective date you are testing against.

Fix it. Two routes work without waiting on the US law. Rehearse against a jurisdiction whose permanent change already ships in tzdata, since America/Vancouver is permanent UTC-7 in the 2026a release, and confirm no November fall-back fires. Or build a custom test zone that carries the target rule, freeze the clock to the boundary, and run the jobs against it.

Verify. Assert that recurring events fire at the intended wall-clock time across the boundary, that payroll and billing show no phantom extra or missing hour, and that reports bucket into the right day.

Automate in CI. Run the scheduler and billing against a fixture clock pinned to the transition, and keep America/Vancouver as a standing regression fixture so the permanent, no-fall-back case is exercised on every build.

Sources

The bill and its passage

How the change reaches software

Finance

The global picture, precedent, economics, and history