Daylight Saving Time Is Not a Feature. It Is an Ambush.
Why the bi-annual clock change is a threat to data integrity, and how to prevent 'The Phantom Hour' from corrupting your payroll and logs.
The Rupture in the Timeline
Human beings perceive time as a continuous river. It flows forward, second by second, without interruption. This is a comforting illusion. In the world of systems administration, time is a fractured landscape, sabotaged by politicians.
Daylight Saving Time (DST) is not a shift; it is a rupture.
In the Spring, we perform a “Gap.” The clock strikes 01:59:59 and then instantly becomes 03:00:00. The hour between 2 AM and 3 AM simply ceases to exist.
In the Autumn, we perform a “Fold.” The clock strikes 01:59:59 and then resets to 01:00:00. The hour happens twice.
The Machine requires causality. Cause must precede effect. If an event happens at 1:30 AM (Version 1) and another happens at 1:30 AM (Version 2), The Machine cannot determine which came first. This destroys the chain of evidence.
The False Security: The Local Timestamp.
Most SMBs operate on “Local Time.” Their servers are set to the timezone of their headquarters. They believe this simplifies operations.
Consider a logistics company paying drivers by the hour.
- Scenario A (Spring): The driver works an 8-hour shift overnight. The clock jumps forward. The timesheet shows 9 hours. You overpay.
- Scenario B (Autumn): The driver works an 8-hour shift. The clock falls back. The timesheet shows 7 hours. You underpay. The driver sues.
This is not a software bug. It is a logical fallacy. You are measuring duration using a ruler that changes length while you are using it.
The Mathematical Reality: The Monotonic Count.
To protect liability and financial accuracy, we must abandon the civil clock for storage. We must use a Monotonic Clock.
This means we rely on Coordinated Universal Time (UTC). UTC does not jump. It does not observe holidays. It is a straight line.
If we store the driver’s shift in UTC:
- Start:
2025-11-02T06:00:00Z - End:
2025-11-02T14:00:00Z
The duration is exactly 8 hours. It does not matter what the clocks in London or New York were doing. The mathematics hold.
Strictly speaking, you should never schedule critical maintenance or financial batches between 01:00 and 04:00 Local Time. This is the “Death Zone.” If you must run jobs then, they must rely on UTC.
Do not let a politician’s decree corrupt your database. Store the absolute truth. Display the local fiction only when necessary.
FAQs
Why does DST matter for non-24/7 businesses?
Because computers are 24/7. Your scheduled tasks, security patches, and audit logs do not sleep. They run during the danger zone.
Can't the software handle the switch automatically?
Software creates the problem. It blindly follows the clock. Unless explicitly told to ignore local time, it will corrupt the sequence.
Is this why my reports look weird in March?
Yes. If you aggregate data by 'Day', and one day has 23 hours, your averages are mathematically incorrect.