Daylight Saving Time Explained
Daylight saving time is not just a political annoyance. It changes offsets, creates nonexistent local times, duplicates others, and regularly breaks assumptions in software and operations.
What actually changes
When daylight saving time begins, a local clock jumps forward by an hour. When it ends, an hour is repeated. That means the local timeline is not always smooth and continuous, even if UTC remains stable underneath.
A meeting scheduled in one city can therefore map to a different local time in another city depending on the month. The offset between New York and London is not constant all year because the regions change clocks on different schedules.
Why it creates bugs
Software often fails when it assumes every local day contains exactly 24 hours. On a spring-forward day, one local hour does not exist. On a fall-back day, one local hour happens twice. If your code stores only a local wall-clock time without a time-zone rule, it may not know which moment the user meant.
These issues show up in payroll, reminders, booking systems, cron jobs, and analytics pipelines. They are not edge cases if your product touches real-world schedules.
How to handle it safely
Use IANA time-zone identifiers such as America/New_York rather than fixed abbreviations or hardcoded numeric offsets. Store the underlying moment in UTC, then convert it for display using the correct zone rules for the event date.
If the user is scheduling something local, keep both pieces of information: the local intended time and the zone. That preserves meaning when daylight saving rules change or when people later view the event from another location.
Put it into practice
Use these tools to apply what this guide covers.
Continue learning
Move laterally into the adjacent concepts that support the same family of date-and-time questions.