Time in the USA

[.Scott]

For the most part, Astronomy finds the time, Physics keeps the time, Politicians decide what to call it, and Software Engineers tell it.

On August 4, 2026, President Trump posted this on Truth Social:

"For many years, the vast Majority of Americans have asked to make Daylight Saving Time permanent, but no Administration has been able to get it done, until now. I am proud to announce that the House of Representatives has passed the Bill, and it has now gone to the Senate for final approval." "People are sick and tired of having to change their clocks twice a year." ... “This is an issue that Republicans, Democrats, and Independents can unite behind. I am asking Republican Senators to release their holds, and allow the hotline to clear on the Republican side.”

While many in the US are wondering what will happen to their sunsets, software engineer's need to be thinking about what this will do to their systems.

The Sunshine Act is in the US Senate - and Trump is hoping it will land on his desk (for his signature) before Nov 30.

The primary problem is not that the clocks will change (or not change), but that the rules for local dates and times occurring after Nov 30, 2026 would change.

So what we are now calling Dec 1, 2026 2pm New York local time, would become described as Dec 1, 2026 at 3pm local time.

This encoding process is based on "time zone" information - and almost every computer in the world keeps this time zone information saved away somewhere on its local drive. All of those computers have a method for converting December times between US local times and UTC. Information that would become outdated the moment that Trump inks his name on this new Act.

There is another issue tied to this - and that is exactly what kind of information is represented by a time value stored in a database or otherwise processed by software. It's enough to call it a "time" in casual conversation, but with computer system design, we may need to explicitly maintain the context of how it was specified and how it will be used.

If a computer system works entirely in UTC (Coordinated Universal Time) and is completely ignorant of local time, then there will be no issues with how times are specified and the context will never be attached to a regular time zone - though system procedures external to the computer may be impacted.

As a side note, I am presuming that the UTC time itself is no issue. All consumer computer systems are expected to sync their clocks using the Network Time Protocol, GPS, or other method.


Here are some scenarios.

Scenario 1:
Let's say it's October and you're on a business trip in London. You'll be leaving in a few weeks. But before returning to your home base in Los Angeles, you will be spending another work week in Boston. You have a tooth that has been bothering you and so you set up an appointment at some Boston dentist at an opportune time - say 7:30am Dec. 4.

Considerations: The key point is that the 7:30am value is not absolute. It is tied to geography and dependent on the time zone information. If Trump signs, the actual time of your appointment changes, and the new appointment time will be called "7:30am", just as it was before.
The entire context of your dialogues for setting and checking the appointment are based on the time and location of the dentist office. Ideally, that "7:30am" time value would be saved along with enough information to determine the geography it is tied to (Boston). If this is done, the corresponding UTC can be recomputed from updated timezone information. Otherwise, if the timezone information is applied immediately, then that UTC value would need to be corrected upon Trump's signature - to keep it at 7:30am local time.

Scenario 2:
While in the Boston area, you want to collect sea shells. So you want to visit a North Shore beach an hour before low tide - and depart your hotel 30 minutes before that. So you set an alarm on your mobile phone for that time.

Considerations: In this case, the user wants to set the alarm to an absolute time. The key problem will be that the calendar app is unlikely to have an option for that kind of setting. The user (or their AI) will also need to be aware that the local times reported in local tide tables may be either pre-Trump or post-Trump values. So they (or their AI) should be using the UTC values in the table. Of course, all of that might be too confusing for your average user.
Ideally, the low tide value will be captured directly from source material (published tables or apps) in a form that is recognized by the alarm app as an absolute time.
Realistically, this will happen no time soon.

------

The other issue is that time zone information.

A primary resource for sharing time zone information is the TZ Database.
Looking over their records, they seem to get an updated release out within about 2 months of when a government changes those rules. Although I expect they would rush things for the Sunshine Act. The current release (2026c) was publish in July.


More practically, your operating system should have the time zone information it needs to support your system.

For Windows, it is kept in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Most Window's systems are set to automatically update at Microsoft's whim. And I would predict such a whim soon after Trump signs.

For Unix-like systems, the time zone info is in this folder:
/usr/share/zoneinfo/

That folder is updated by the OS developers in response to changes to the TZ Database.
Those changes would result in a system update. In most cases, it is the users responsibility to download and use those updates.

macOS and iOS are similar to Unix.

 

[PeroK]

I don't see the problem. Not every country changes its clocks. It would just mean a general configuration file change in the US.

 

[256bits]

A re-hash with some links of the complexity of present day timekeeping.

The world depends upon accurate time stamps, past present and future, so all operating systems and programs should determine such things as local time where you are located, local time where some one else is located, in relation to some kind of world time such as UTC ( ZULU in the airline industry ) or GMT, upon which a civil time can be agreed upon for commerce, the public, and government to function properly. Even something silly ( one would normally not consider it ) such as framework of storage medium can automatically determine how time stamps are set ( unless I am mistaken, USB drives can use FSB( local time ), NTSF ( UTC ) ) can cause confusion with time comparisons.

Along with DST, the calendar itself has to synchronized due to leap years, and leap seconds. Somewhere, someone must be keeping track of the leap seconds changes to the clock. If not handled correctly in this digital age of computers and internet, satellites, databases, deviations from what is expected can result.

The whole time keeping thing is a nightmare and mess for everybody. Those just poking along on the keyboard never contemplate what is really under the hood, as it is all hopefully done automatically by some outside agency, say Microsoft through their operating system. Seem to remember some scare about planes falling out of the sky and the world coming to an end at midnight as all the computer clocks were going to reset to some back date.

Thankfully, for the DST, some person years ago decided to tabulate the DST changes around the world, and make a database of it, so you don't have to do it on your own. And get sued for all the effort by some map guy, who eventually dropped the case by some stern talking to ( from his mother no doubt ).

The tz database used by all major, and minor, whose-who of the digital world to keep you on time for your appointments.
https://data.iana.org/time-zones/tz-link.html#coordinating
https://en.wikipedia.org/wiki/Tz_database <<-- same reference as .Scott

Here is chronos from C++ to show all the clocks and functions that go into keeping 'time' timely. C++ keeps on adding stuff, most that should have been in there from the beginning, but as tech progresses so do extras add on. ( ie GPS wasn't publicly available until 1988, but does not record leap seconds. Using the GPS signal as a timestamp shows an 18 second difference from actual UTC ). Some of the C++ stuff may still yet rely upon the original C.
https://en.cppreference.com/cpp/chrono
https://en.cppreference.com/c/chrono

Note the description at the top of the page of the types of clocks that operating systems or programs can keep track of. Your smart phone probably has all now; older systems would have not.
http://www.leapsecond.com/java/gpsclock.htm

 

[.Scott]

I don't see the problem. Not every country changes its clocks. It would just mean a general configuration file change in the US.

No:
1) That "configuration file" is generally an entire directory structure.
2) This type of information resides on most consumer computers world-wide - not just the US. For example, earlier this year Alberta Canada changed its time zone rules. That change went through the process I described in the OP - and if your OS has been updated recently, that update will be residing on your computer - and available to software on your computer.

Perok: I don't see the problem.
The issue is routine. The OP was addressed primarily to Software Engineers on a matter related to proper data normalization.

From a user point of view:
The OP is not intended to be alarming in any way.
If Trump signs this too close to November 30, there will probably be noticeable problems with US December times (no matter what part of the planet you're using). Otherwise, most users (99%) will never see a problem.
But it's probably still worth mentioning that user impact is possible - just a heads up.