Why Timezone Info is More Than Just an Offset

An ISO 8601 timestamp with an offset, like 2025-04-20T19:19:16+02:00, is great for pinning down an absolute point in time. It tells you exactly when something happened relative to UTC, which is usually what you want. Until it isn’t: Sometimes, knowing the absolute point in time via UTC just isn’t enough. This happens when time is tied to a specific place and the way time works there. That’s where the timezone name comes in.

Think about scheduling an event. If someone in New York sets a meeting for “November 5th, 2023 at 10:00 AM”, they’re thinking in their local time. If we just saved that as a UTC timestamp back when they created it, and then New York’s Daylight Saving Time rules shifted before the event, looking at that old UTC timestamp could suddenly show a time that isn’t 10:00 AM local anymore. This completely messes with the user’s original intention for the meeting time.

The better way to handle this is to store the event’s local time components alongside the timezone name, like “America/New_York”. This way, your application can use a proper timezone database (the kind that knows all the historical and future DST changes) to figure out the correct absolute time for “November 5th, 2023 at 10:00 AM in America/New_York” whenever you need it. This guarantees the event always shows up as 10:00 AM local time for people in New York, no matter what timezone rule weirdness happens in between. Crucially, this means that your timestamp becomes fuzzy, as it now depends on the IANA timezone database.

So, for things like calendar appointments, reminders, or anything where the local time as the user understood it is critical, storing the timezone name isn’t just a nice-to-have, it’s essential. It’s about capturing the context of time in a specific location and being able to deal with the fact that time rules aren’t always static.

If you still feel like “surely this is a solved problem?”, take a look at RFC 9557. It’s an update to the internet’s time standard (RFC 3339, which is based on ISO 8601) specifically to allow including extra info like the timezone name. The RFC was published in April 2024 (timezone unknown 🙈).