Working with Timezones in Web Development

The Challenge of Timezones

Timezone bugs are the kind that hide for months. Everything works in testing because your server and your laptop are in the same timezone. Then you deploy to a region in a different offset and suddenly scheduled tasks run at the wrong time, timestamps sort incorrectly, and date ranges are off by a day. And that's before DST even enters the picture.

A user in New York, a server in London, and a database in Singapore might all interpret the same timestamp differently. Getting this wrong leads to missed meetings, incorrect schedules, and frustrated users.

UTC: Your Foundation

Coordinated Universal Time (UTC) is the foundation of modern timekeeping. It's the time at the Prime Meridian (0° longitude) and doesn't observe daylight saving time. Every timezone is defined as an offset from UTC.

• UTC-5: Eastern Standard Time (US)
• UTC+0: London (during winter)
• UTC+9: Japan Standard Time
• UTC+5:30: India Standard Time

Daylight Saving Time

DST is where timezone handling gets truly complex. Not all countries observe DST, and those that do switch on different dates. Some regions within countries don't observe DST (like Arizona in the US). Rules have changed historically and may change in the future.

Key considerations:

• DST creates a "spring forward" where an hour doesn't exist
• DST creates a "fall back" where an hour occurs twice
• Never hard-code offset values; use timezone databases
• Historical dates may have different DST rules than today

Best Practices

1. Always Store UTC

Store timestamps in UTC in your database. This is non-negotiable. When you need to display times to users, convert from UTC to their local timezone at the moment of display.

2. Use Timezone-Aware Libraries

Don't try to handle timezones manually. Use established libraries:

• JavaScript: Luxon, date-fns-tz, Day.js with timezone plugin
• Python: pytz, dateutil, pendulum
• Java: java.time (Java 8+)

3. Store User Timezone Preferences

Don't assume all users are in one timezone. Store their preference and use it consistently. The IANA timezone database identifiers (like "America/New_York") are the standard format.

4. Be Explicit in APIs

When exchanging timestamps via APIs, use ISO 8601 format with explicit timezone information:

// Good - includes timezone offset
"2026-02-15T14:30:00-05:00"

// Good - UTC indicated with Z
"2026-02-15T19:30:00Z"

// Avoid - ambiguous local time
"2026-02-15T14:30:00"

5. Handle Edge Cases

Consider what happens during DST transitions. If a user schedules something for 2:30 AM on a DST transition day, what should happen when that time doesn't exist or occurs twice?

Common Mistakes

• Using local time in databases: Creates confusion when servers move or data is accessed from different locations
• Calculating offsets manually: Breaks when DST rules change
• Ignoring user timezone: Shows wrong times to international users
• Storing timezone offset instead of timezone ID: Offsets change with DST; IDs handle this automatically

Conclusion

Timezone handling requires careful attention to detail, but following established patterns makes it manageable. Store everything in UTC, use proper libraries, be explicit about timezones in your APIs, and always consider your international users. With these practices, you can build applications that handle time correctly no matter where your users are located.