Clocks Fall Back Sunday. Will Your Data Count 1 AM Twice?

One hour, written twice

At 2 AM local time on Sunday, November 1, clocks in Oklahoma go back to 1 AM. Then the hour from 1 AM to 2 AM plays again. Most people just get more sleep.

Your systems do not sleep. Orders, shipments, meter reads, patient visits and time clock punches keep coming in. If they are saved in local time, a row stamped during that hour gives no clue which pass of the hour it came from.

What the evidence says

Federal law sets the dates. Under 15 U.S.C. 260a, daylight time runs from 2 AM on the second Sunday of March to 2 AM on the first Sunday of November. A state can opt out only by staying on standard time all year.

Oklahoma has tried to go the other way. Senate Bill 1200 passed the Senate 37 to 9 and the House 67 to 29, and the Governor signed it on April 26, 2024. It puts Oklahoma on daylight time all year, but only once a federal law allows it. CBS News reports that the Sunshine Protection Act passed the U.S. House in July and stalled in the Senate. So the clocks fall back this Sunday and spring forward again on March 14, 2027.

Microsoft's SQL Server documentation describes the problem plainly. When clocks are set back, two hours of local time overlap onto one hour. The same page notes that SQL Server takes its time zone rules from outside the database, from the operating system.

Scheduled jobs feel it too. Redgate's backup documentation says a log backup set to run every 5 minutes will have a one hour gap at fall back, and that this affects every SQL Server Agent job. Paul Randal of SQLskills gives the same example with a 15 minute job. The gap stretches to 75 minutes. If you promise no more than 15 minutes of lost data after a failure, that promise is open for more than an hour.

The cloud platforms already lean one way. Microsoft recommends UTC for the data tier because it removes this kind of doubt, and Azure SQL Database always runs in UTC. PostgreSQL stores its timestamp with time zone type as UTC inside the database.

Where the repeated hour causes trouble

Timestamps without an offset

A plain date and time column saves the clock reading and nothing else. On Sunday morning, two rows can show the same reading even though they were saved an hour apart. Sorting by time mixes them together. A shift that starts at midnight and ends at 3 AM looks like three hours on the clock but was four hours of real work.

Scheduled jobs that pause

SQL Server Agent jobs follow the server's local clock. When 2 AM turns back into 1 AM, the next run time does not move back with it. Log backups, data loads and early reports simply wait an hour.

Spring brings the opposite problem

In March the hour from 2 AM to 3 AM never happens. Redgate notes that jobs which are now overdue all run at once and can collide. A job set to run inside that missing hour needs a plan too.

Servers that do not agree

An app server in UTC, a database in Central time and a reporting tool in the user's own zone will each tell a different story about the same event. For Azure SQL Managed Instance, Microsoft advises keeping a primary and its secondary in the same time zone, and it reads restore points in UTC.

What to check before the clocks change

1. 1List every scheduled job that runs between midnight and 3 AM, including backups, data loads and reports.
2. 2For log backups, decide whether a gap of an hour or more is acceptable. If not, plan one extra run with a unique file name.
3. 3Find the columns that store local time with no offset. Mark the ones that feed billing, payroll or compliance reports.
4. 4For new tables, store time in UTC or in a type that keeps the offset, such as datetimeoffset in SQL Server or timestamptz in PostgreSQL. Convert to Central time only when you show it to people.
5. 5Confirm that primary and secondary servers use the same time zone.
6. 6On Monday morning, compare row counts and totals for the 1 AM hour with a normal night.
7. 7Put March 14, 2027 on the calendar and run the same review for the spring change.

Changing the time zone of a live system is a bigger job. Microsoft notes that a managed instance's time zone cannot be changed after it is created. Plan that kind of move with care rather than over a weekend.

What this means if you run a company in Oklahoma

Until Congress acts, Oklahoma changes its clocks twice a year. If your business runs overnight, like a plant, a hospital, a trucking dispatch or a field operation, data keeps flowing through that hour. The fixes are not hard. Someone just has to look before Sunday and decide how your systems will store time from now on.

At Oklahoma Data Partners, we work only on data and only in Oklahoma. We review overnight jobs, backup timing and how your databases store time, then help you fix what we find before it shows up in a report. If you want a second set of eyes on your systems, book a consultation.