Ask a software developer what the hardest problems in computing are, and time zones will almost certainly make the list (right after naming things and cache invalidation). The challenge is not just that there are many time zones. It is that the rules governing them change constantly, retroactively, and sometimes with only a few weeks' notice. Handling time correctly in software requires understanding a surprisingly deep stack of standards, databases, and edge cases. The good news is that the tooling has improved enormously over the past decade, but the underlying complexity remains.
The IANA Time Zone Database
At the heart of timezone handling in software is the IANA Time Zone Database, often called tzdata or zoneinfo. Maintained by a small community of volunteers (coordinated by ICANN), this database contains the complete history of UTC offsets and DST rules for every region in the world. Each entry uses a Region/City identifier like America/New_York or Asia/Kolkata. The database is not just a list of current offsets. It records every historical change, so software can correctly determine what the local time was in any timezone at any point in the past. Operating systems (Linux, macOS, Windows, Android, iOS), programming languages (Java, Python, JavaScript, Go, Rust), and databases (PostgreSQL, MySQL) all ship with or reference this database. Updates are released several times a year, typically when a country announces a change to its DST rules or UTC offset. A notable example: when Samoa skipped December 30, 2011 to jump across the International Date Line, the tzdata update had to encode a day that literally did not exist.
Unix timestamps and UTC
A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC (known as the Unix epoch). This number is timezone-agnostic: Unix timestamp 1709654400 represents the same instant everywhere on Earth. Converting a Unix timestamp to a human-readable date requires knowing the viewer's timezone. This is why the standard advice is to store time as UTC (or Unix timestamps) and convert to local time only at display time. If you store a time as "3:00 PM Eastern," you have baked in an assumption about timezone and DST state that may not hold in the future. If you store it as a UTC timestamp, the conversion can always be recalculated using the latest timezone rules.
Common pitfalls developers hit
One classic mistake is using timezone abbreviations (like CST) as identifiers. CST is ambiguous (Central Standard Time in the US, China Standard Time, Cuba Standard Time). Always use IANA names. Another common error is assuming UTC offsets are fixed. America/New_York is UTC-5 part of the year and UTC-4 during DST. Code that hardcodes "-5" will be wrong for half the year. A third trap is assuming DST transitions happen at midnight. In most US time zones, the switch happens at 2:00 AM. During the "spring forward" transition, the minute after 1:59 AM is 3:00 AM, meaning 2:00 AM to 2:59 AM simply does not exist. During "fall back," 1:00 AM to 1:59 AM happens twice. Scheduling systems and logging tools need to handle both cases. A fourth pitfall is assuming all offsets are whole hours, which produces wrong results for the 500+ million people living in half-hour and quarter-hour zones.
Leap seconds and the 2035 deadline
UTC includes leap seconds, irregular one-second adjustments to keep atomic time aligned with Earth's rotation. Since 1972, 27 leap seconds have been added. Most operating systems handle leap seconds by "smearing" them (gradually adjusting the clock over a period of hours) rather than inserting a literal second 23:59:60. This smearing approach means that during a leap second event, timestamps from different systems may disagree by up to half a second. In November 2022, the General Conference on Weights and Measures voted to abolish leap seconds by 2035, allowing UTC to slowly drift from solar time. This will simplify timekeeping in software but may require changes to systems that currently account for leap seconds. For most developers, the practical impact of leap seconds is minimal, but systems that need sub-second accuracy (financial trading platforms, scientific instruments, GPS receivers) must handle them carefully.
Best practices for developers
Store all timestamps in UTC or as Unix epoch values. Use IANA timezone identifiers, never abbreviations. Use a mature timezone library (date-fns-tz, Luxon, java.time, pytz/zoneinfo) rather than rolling your own offset calculations. Keep your system's tzdata package updated, since timezone rules change several times a year. Test your code around DST transitions, especially the "spring forward" gap and the "fall back" overlap. When displaying times to users, always show the timezone alongside the time. And if your application deals with future dates, remember that the timezone rules for that date may not yet be finalized, especially in countries that announce DST changes with short notice. One more thing: never trust user-supplied timezone abbreviations. If your system accepts "CST" as input, force the user to disambiguate. Three letters is not enough to identify a timezone.