How to Handle Timezones in Software Without Going Insane
Why UTC is your best friend and how to never lose an hour again.
The Problem That Makes Dates Lie
Imagine you schedule a meeting for 3 PM. But the person on the other side of the world sees it as 2 AM. What happened? Timezones. A timezone is a region of the world where everyone agrees on what time it is. There are 24 of them, one for each hour in the day — but it's messier than that because countries also shift their clocks for daylight saving time.
Here's the core rule you need to remember: a date and time without a timezone is meaningless. "3:00 PM on June 15th" could mean anything. Is that Toronto time? Tokyo time? UTC?
When software stores a time, it needs to know where on Earth that time applies. The simplest fix? Store everything in UTC — Universal Coordinated Time, the time zone that Greenwich, England uses. UTC never changes for daylight saving. It's the common language all computers can agree on.
Then, when showing a time to a user, you convert it to their local timezone. This two-step process (store in UTC, display in local) is the secret to sane datetime handling.
Why Your App Will Break Without This
Timezone bugs are silent. They don't crash your app. They just show the wrong time, which can cause real problems: a user missing their flight because the ticket showed the wrong departure time, a message sent at 3 AM instead of 3 PM, a scheduled reminder firing on the wrong day entirely.
The stakes get higher when your app serves people across multiple countries. A booking system that only understands one timezone will frustrate everyone outside it. An analytics dashboard that mixes timezone data will produce charts that nobody can interpret correctly.
💡 Key Insight
The most common timezone mistake: storing dates as a string like "2026-06-15 15:00" without a timezone. It looks fine until someone in a different country opens it. Always store datetimes with their timezone or, better yet, convert to UTC first.
The Three Rules of Timezone Sanity
Follow these three rules and timezone chaos stays away:
Store in UTC
Always convert user input to UTC before saving to your database. This is your single source of truth. Whatever timezone the user was in when they created the data — it doesn't matter. UTC it.
Convert at Display
When showing a time to a user, convert from UTC to their local timezone. Most programming languages have a library for this — use it. The user's browser also knows their timezone via Intl.DateTimeFormat.
Use Timestamps, Not Strings
Store dates as actual datetime objects or Unix timestamps, not strings like "June 15". Strings lose timezone info and sorting gets weird. A Unix timestamp is just a number — 1,749,123,600 means one specific second, anywhere.
Here's the typical flow: a user in Tokyo books a call for 6 PM their time. Your app converts 6 PM Tokyo to UTC (which might be 9 AM UTC). It stores 9 AM UTC in the database. Later, a user in New York opens the booking — your app converts 9 AM UTC to 5 AM New York time and shows it correctly.
Converting a Time to UTC (and Back)
Here's how this looks in JavaScript — one of the most common languages for web apps:
// Step 1: User in Toronto picks 3:00 PM local time const torontoTime = new Date('2026-06-15T15:00:00'); // This is "2026-06-15 15:00:00" in Toronto (UTC-4 during summer) // Step 2: Convert to UTC for storage const utcTime = torontoTime.toISOString(); // Result: "2026-06-15T19:00:00.000Z" — that's 3 PM Toronto = 7 PM UTC console.log(utcTime); // → 2026-06-15T19:00:00.000Z // Step 3: Show it to a user in Tokyo (UTC+9) const tokyoTime = new Date(utcTime); const formatted = tokyoTime.toLocaleString('en-JP', { timeZone: 'Asia/Tokyo', hour: '2-digit', minute: '2-digit', hour12: false }); console.log(formatted); // → 04:00 — 7 PM UTC becomes 4 AM Tokyo ✓
The key takeaway: toISOString() always gives you UTC. Store that. Then use toLocaleString() with a timezone option to display it for any user anywhere.
Knowledge Check
Test what you learned with this quick quiz.