.jpg){kind=link}
I had my usual 7:30 PM IST meeting, but Outlook never sent its 15-minute reminder. When I checked my calendar, the meeting had shifted to 8:30 PM. No rescheduling notification, nothing.
Turns out, daylight saving time had just ended in the US.
The meeting hadn’t actually been rescheduled. It was still happening at the same local time for my US colleagues, but since India doesn’t observe daylight saving time, it was now an hour later for me.
That got me thinking. How do servers handle daylight saving time, especially when it comes to logging?
TL;DR: The time zone database tells software which local-time rules apply. Storing timestamps in UTC distinguishes events that share a local time, but an interface still needs to show enough information to tell them apart.
On November 1, 2026, Chicago’s clocks moved backward by an hour. At 2:00 AM CDT (Central Daylight Time), the clock jumped back to 1:00 AM CST (Central Standard Time).
At the end of daylight saving time, 1:59 AM CDT is followed by 1:00 AM CST.
This means the entire hour between 1:00 and 1:59 AM happened twice. Imagine a server logging two requests at 1:20 AM on the same date, but an hour apart. How does it tell them apart? And who tells the server when to change its clock?
Countries on the 2026 list (54)
- Albania
- Australia
- Austria
- Bahamas
- Belgium
- Bosnia and Herz.
- Bulgaria
- Canada
- Chile
- Croatia
- Cuba
- Cyprus
- Czechia
- Denmark
- Egypt
- Estonia
- Finland
- France
- Germany
- Greece
- Greenland
- Haiti
- Hungary
- Ireland
- Israel
- Italy
- Kosovo
- Latvia
- Lebanon
- Lithuania
- Luxembourg
- Mexico
- Moldova
- Montenegro
- Morocco
- N. Cyprus
- Netherlands
- New Zealand
- North Macedonia
- Norway
- Palestine
- Poland
- Portugal
- Romania
- Serbia
- Slovakia
- Slovenia
- Spain
- Sweden
- Switzerland
- Ukraine
- United Kingdom
- United States of America
- W. Sahara
tzdata
There’s a shared database called the IANA Time Zone Database, often called tzdata. It contains historical and current time-zone rules used by operating systems and programming languages.
Let’s take America/Chicago as an example. Its standard offset is UTC−6, and its daylight saving rules add an hour during part of the year. The current US rules translate to:
- March: On the second Sunday of March, clocks move forward by an hour at 2 AM. So 2 AM becomes 3 AM, and Chicago switches from CST (UTC−6) to CDT (UTC−5).
- November: On the first Sunday of November, clocks move backward by an hour at 2 AM. So 2 AM becomes 1 AM again, and Chicago switches from CDT (UTC−5) back to CST (UTC−6).
Software uses these rules to convert an instant into local time. When a government changes a rule, the database can be updated, and operating system or software vendors distribute the updated data. Those updates still need to reach the server; they are not instantaneous.
Given all these quirks of local time zones, it’s a good practice to store log timestamps in UTC to avoid ambiguity.
But that raised another question for me. How do user interfaces handle these changes, especially in banking applications?
Imagine someone makes a transaction at 1:20 AM CDT, just before the clocks move back. An hour later, they make another transaction at 1:20 AM CST. The first is 06:20 UTC; the second is 07:20 UTC.
The backend should have no trouble distinguishing them, assuming timestamps are stored in UTC. But what about the frontend? What does the user actually see?
Two transactions on the same date, both showing 1:20 AM? Or does the app explicitly display 1:20 AM CDT and 1:20 AM CST to distinguish them?
Storing UTC solves the ambiguity in the data, but it doesn’t automatically solve ambiguity in the user interface.