Daylight Saving Time (DST) in IT Architecture: Universal Guide and Cheat Sheet for Developers

For most people, transitioning between Daylight Saving Time (DST) and Standard Time is simply a matter of adjusting the kitchen clock. However, in the IT world, basing a system on a local time zone is a ticking time bomb that usually explodes twice a year, in the middle of the night, causing hard-to-diagnose errors and data loss.

When a server bases its operation on local time, jumping the clock forward or backward by an hour breaks the fundamental rule of computer science: linearity and continuity of time.

In this article, we'll analyze why DST breaks systems, and provide ready, practical solutions for every element of the technology stack (DevOps, Backend, Databases, and Frontend).

Why is Time Change an Architectural Nightmare?

Errors resulting from local time strike at two critical moments:

• Spring Forward: Clocks jump e.g., from 01:59 to 03:00. The hour in between simply "does not exist". If you have a critical Cron job (e.g., database backup or email sending) set for 02:30 – this job will never execute.
• Fall Back: Clocks fall back from 02:59 to 02:00. The same hour happens twice. A record saved at 02:30 before the clock rewinds, and then another record at 02:30 after the rewind, creates a data conflict. The system assumes we went back in time.

The Golden IT Rule: "Store in UTC, Display in Local"

The only effective salvation is an architecture where all servers and databases operate exclusively in UTC (Coordinated Universal Time). UTC time is not subject to summer/winter changes. Seconds flow steadily and always forward in it.

Conversion to "human" (local) time should only happen at the very end – in the user's browser or phone app.

🛠️ Cheat Sheet: How to handle time correctly?

1. Infrastructure and Servers (Docker / Linux)

As a DevOps or administrator, ensure your containers and servers don't inherit the host's time zone if the host isn't in UTC.

Docker (Dockerfile): Always enforce UTC in application containers.

# Setting the environment variable permanently to UTC
ENV TZ=UTC
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

2. Databases (SQL)

Saving "naive" time (without time zone information) is the most common mistake.

PostgreSQL: Never use TIMESTAMP WITHOUT TIME ZONE. Always use the variant with a time zone (timestamptz). This type transparently converts the time to UTC during saving.

CREATE TABLE user_logs (
    id SERIAL PRIMARY KEY,
    action VARCHAR(50),
    -- ALWAYS use TIMESTAMPTZ
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() 
);

MySQL: Ensure the entire database server speaks UTC.

-- Execute this in the configuration to protect the entire database
SET GLOBAL time_zone = '+00:00';

3. Backend (Python and Node.js)

In the business logic layer, always generate and operate on absolute time.

Python: Avoid datetime.now() (creates a naive datetime based on the server). Always add timezone awareness.

from datetime import datetime, timezone

# ❌ BAD: Depends on the server, breaks during DST
bad_time = datetime.now() 

# ✅ GOOD: Absolute time in UTC
good_time = datetime.now(timezone.utc)
print(good_time.isoformat()) 

Node.js / JavaScript: The Date object in Node.js uses system time by default, but when sending data via API (e.g., as JSON), always use the ISO format.

// ✅ GOOD: Generates a string in UTC with the letter "Z" at the end (Zulu time)
const timestampForAPI = new Date().toISOString(); 

4. Frontend (Browser / Mobile App)

This is where the magic happens. You fetch data from the backend in UTC, and the browser itself knows (from the user's system settings) how to display the local time – correctly taking into account whether daylight saving or winter time is currently in effect.

JavaScript (Frontend): Use the native Intl API, which is built into every browser and doesn't require heavy libraries.

// Data received from the backend API (always in UTC)
const apiUtcDate = new Date('2026-10-25T14:30:00.000Z');

// Conversion to the user's device time zone
const formatter = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'medium',
  timeStyle: 'short'
});

console.log("Local client time:", formatter.format(apiUtcDate)); 

✅ Code Review Checklist

• [ ] Do servers/containers have the TZ=UTC zone set?
• [ ] Do database columns enforce saving with a time zone (e.g., timestamptz)?
• [ ] Does the API communicate with the Frontend exclusively in the ISO 8601 standard (with a Z at the end)?
• [ ] Do Cron tasks use UTC time to avoid the 02:00-03:00 jump in spring?