Working With Time Zones, DST and Date Math Without Bugs
Working with time is one of software's sneakiest traps. An innocent assumption like "a day is 24 hours" can shift your app by an hour during a daylight saving transition; "the offset is fixed" leads to wrong meeting times. In this guide we explain, in plain language, the practical ways to handle time zones, daylight saving and date math correctly.
UTC vs Local Time
Everything rests on UTC (Coordinated Universal Time). UTC is the world's single, unchanging reference clock; it never observes daylight saving, never shifts, never argues. Local time is always expressed as a UTC offset. For example, Turkey time is UTC+3.
The golden rule: build your logic in UTC, display to the user in local time. Use UTC on servers, in the database and in calculations; convert to the user's zone only when rendering. That way a time calculation stays correct no matter where the user is.
IANA Time Zones: Region, Not Offset
A common mistake is to store a time zone as a fixed offset like "UTC+3." The problem: offsets change during the year. In countries that observe daylight saving, the same city can be UTC+1 in winter and UTC+2 in summer.
The correct approach is to use IANA time zone names: Europe/Istanbul, America/New_York, Asia/Tokyo, and so on. These names carry not just an offset but the region's full daylight saving rules and historical changes. When you combine a date with Europe/Berlin, the system automatically knows whether DST applied on that date.
| Region | IANA name | DST |
|---|---|---|
| Istanbul | Europe/Istanbul | No (fixed UTC+3) |
| London | Europe/London | Yes |
| New York | America/New_York | Yes |
| Tokyo | Asia/Tokyo | No |
| India | Asia/Kolkata | No (UTC+5:30) |
Daylight Saving (DST) Pitfalls
DST is the most productive source of bugs. Three scenarios to watch:
- The missing hour: When clocks spring forward, the window from 02:00 to 03:00, for example, simply vanishes. A time created in that range is invalid.
- The repeated hour: When clocks fall back, 02:00 to 03:00 happens twice. "01:30" is ambiguous: which transition?
- The fixed-offset assumption: "Compute the difference once and reuse it" gives a wrong answer for an hour after every transition.
The fix, again, is the same: do your math in UTC. UTC knows nothing of daylight saving, so none of these pitfalls can occur in UTC.
Scheduling Across Zones
When you plan a meeting with attendees from different countries, always anchor it to a single absolute instant. "Tuesday 3:00 PM" is not enough; you must say "Tuesday 3:00 PM Europe/Istanbul." The system converts that instant to UTC, then displays it to each attendee in their own local time.
Remember that across borders the clock, and even the date, can jump: a meeting that is Wednesday morning in Istanbul is still Tuesday night in Los Angeles. For quick conversions you can use our time zone converter and then write the result into the invitation.
Computing the Difference Between Two Dates
When finding the number of days between two dates, use UTC to strip away the hours; otherwise DST can add an hour and produce wrong results like "less than 1 day."
Business-day math is a separate matter: you must exclude weekends and public holidays. When you quote a deadline as "10 business days from now," be careful not to confuse calendar days with working days. For these calculations our date difference tool returns results in days, weeks and business days. To learn how much time has passed from a birth date to today in years, months and days, try the age calculator.
Storing Timestamps
When persisting data, stick to one rule: always UTC, always ISO 8601. The ISO 8601 format (2026-06-14T12:30:00Z) is readable to both machines and humans; the trailing Z says the value is UTC. Storing local times without an offset (2026-06-14 12:30) is the most common and most expensive mistake, because you can never reliably recover which zone that instant belonged to.
The Most Common Bugs
- Storing dates in local time without an offset.
- Always counting a day as 86,400 seconds (not true under DST).
- Keeping a time zone as a fixed offset instead of an IANA name.
- Assuming the server and client clocks share the same zone.
- Showing the user raw UTC time as-is.
Summary
Time looks complicated but tames with discipline: store and compute in UTC, name zones with IANA identifiers, display to the user in local time. Stay faithful to those three principles and DST transitions, date jumps and offset confusion stop being bug sources and become ordinary details.