Why "UTC+1" Is the Wrong Way to Represent a Timezone — DST, the IANA Database, and Ambiguous Hours

Daylight Saving Time doesn't just shift what the clock shows — it changes the UTC offset for every timezone that observes it, which means the correct conversion between two timezones in summer is different from the correct conversion in winter, and software that hardcodes offsets instead of using timezone databases gets this wrong every year

The previous articles on this site covered UTC offsets and DST basics, the world's strangest timezones, and scheduling across timezones. This article addresses how computers represent timezone information — specifically why hardcoding UTC offsets is wrong, what timezone databases actually contain, and what happens when DST rules change and your software doesn't know yet.

UTC offsets vs timezone identifiers: a critical distinction

"UTC+5:30" is a UTC offset. It tells you the current difference from UTC, right now. It does not tell you whether this offset applies year-round or changes seasonally.

"Asia/Kolkata" is a timezone identifier. It refers to a named timezone with a defined set of rules: the current UTC offset, historical UTC offsets, whether DST is observed, when DST transitions occur, and any rule changes over time.

India (Asia/Kolkata) is permanently UTC+5:30 — no DST. For India, "UTC+5:30" and "Asia/Kolkata" are equivalent in practice. But "UTC+1:00" is ambiguous — it could be London in winter (Europe/London is UTC+0 in winter and UTC+1 in summer), Paris in winter (Europe/Paris is UTC+1 in winter and UTC+2 in summer), or West Africa Time (Africa/Lagos, permanently UTC+1 with no DST). The same UTC offset can represent different places at different times of year.

The IANA timezone database: what it actually contains

The IANA timezone database (also called "tz database" or "tzdata") is the canonical source for timezone rules worldwide. It's maintained by an IANA working group and updated multiple times per year as countries change their DST rules.

What it contains per timezone:

• Historical and current UTC offsets
• DST transition dates and times (which day of year, which week of month, which specific date)
• Historical changes to those rules (what the rule was before a certain year)
• Edge cases (regions that observed DST for one year and then stopped)

Countries change their DST rules more often than you'd think — in 2022, Finland announced it was considering abolishing DST (a politically contentious EU-level issue); Turkey abolished DST in 2016 and permanently adopted UTC+3; Morocco has a particularly complex rule where DST is suspended during Ramadan. Each of these required an update to the IANA database — and software using outdated timezone databases would calculate incorrect conversions for those regions.

Why hardcoded UTC offsets break twice a year

"New York is UTC-5" — accurate in winter. In summer, New York is UTC-4 (EDT — Eastern Daylight Time). Hardcoding UTC-5 for New York means:

• Correct from early November to mid-March (EST period)
• Wrong from mid-March to early November (EDT period) — off by one hour

At scale, this mistake is widespread. It appears in:

• Configuration files that store user timezone as a UTC offset rather than a timezone identifier
• APIs that return timestamps with hardcoded offset adjustments rather than correct timezone-aware conversions
• Meeting schedulers that calculate times based on current offset without accounting for upcoming DST transitions
• Calendar events that "drift" by an hour if stored with an absolute UTC offset that's recalculated at a different point in the year

The fix: always store and work with IANA timezone identifiers, not UTC offsets. When you need to display a time in a user's local time, convert using the timezone identifier and current rules — not a stored offset.

The "spring forward" / "fall back" boundary edge cases

DST transitions create genuinely ambiguous moments:

Spring forward (clocks jump from 2:00 AM to 3:00 AM): the hour between 2:00 AM and 3:00 AM doesn't exist on the day clocks spring forward. A meeting scheduled for 2:30 AM on that day is ambiguous — 2:30 AM doesn't exist.

Fall back (clocks go from 2:00 AM back to 1:00 AM): the hour between 1:00 AM and 2:00 AM occurs twice on the day clocks fall back. 1:30 AM occurs twice. Without specifying which occurrence, 1:30 AM on that day is ambiguous.

How databases handle this: ISO 8601 timestamps with explicit UTC offsets or Z suffix (e.g., 2024-03-10T07:30:00Z) are unambiguous — converting to local time is a display concern, not a storage concern. Storing 2024-03-10 02:30:00 in "New York time" without a UTC offset is ambiguous — it's the time that doesn't exist.

Half-hour and 45-minute offset timezones

Not all timezone offsets are whole hours. Some notable non-hourly offsets:

UTC+5:30 (India): the most populous country with a non-hourly offset — affecting 1.4 billion people.

UTC+5:45 (Nepal): the only UTC+5:45 timezone — also the only 45-minute-offset timezone currently in use.

UTC+9:30 (Australia/Adelaide, Darwin): half-hour offset in Australia's central zones.

UTC+3:30 (Iran): and UTC+4:30 (Afghanistan, no DST; and Iran during DST).

These create edge cases in naive software that assumes all timezone offsets are whole hours — particularly when displaying clocks or calculating times modulo hours.

How to use the Time Zone Converter on sadiqbd.com

1. Use timezone names or cities, not UTC offsets, when specifying locations — "London" or "Europe/London" rather than "UTC+0" or "UTC+1" (which would be ambiguous between winter and summer)
2. For future event scheduling: convert using the rules for the target date (DST may or may not be in effect), not the rules for today — some converters calculate correctly for future dates with DST transitions, some don't; verify yours does
3. For overlapping DST transition periods: major timezones don't all switch on the same date — the US switches a few weeks before the EU, creating a brief period where the offset between, e.g., New York and London differs from the usual value

Frequently Asked Questions

If I'm building an application, should I store times as UTC and convert for display? Yes, this is the standard recommendation. Store everything as UTC (or as Unix timestamps, which are implicitly UTC); apply timezone conversion at display time using the IANA database and the user's timezone identifier (not a stored UTC offset). This approach avoids all the DST-transition bugs — UTC times are unambiguous, and the conversion to local display happens correctly using current rules at the time of display. The common mistake is storing times in "local time" (without timezone identifier or UTC offset), which becomes ambiguous when DST transitions occur or when the timezone rules change.

Is the Time Zone Converter free? Yes — completely free, no sign-up required.

Try the Time Zone Converter free at sadiqbd.com — convert times between any world timezones, correctly accounting for DST.