Time Zone Converter
Convert a date and time between time zones, seeing the real UTC offset and whether daylight saving is in effect. A world clock runs alongside.
A time zone is not an offset
This is the distinction that breaks scheduling software. An offset is a
fixed shift from UTC — +08:00. A time zone is a
geographic region with a history of offsets:
Europe/London is +00:00 in winter and +01:00 in
summer, and it was -00:44 for part of the nineteenth century.
So "add 8 hours" is not a conversion. If you store +08:00 against a meeting
in March and the meeting is in November, you will be an hour wrong in any zone that
observes daylight saving. The only durable representation is an instant (UTC, or an epoch
value) plus an IANA zone name, letting the offset be looked up for the moment in question.
Store the zone, not the offset. A database column holding
+02:00 is already wrong for half the year. Holding
Europe/Berlin stays correct through every future rule change, because the
IANA database is updated and the lookup happens at read time.
Daylight saving produces two impossible hours
When clocks go forward, a stretch of local time simply does not exist — in most of
Europe, 02:30 on the last Sunday of March never happens. When clocks go back, an hour
occurs twice: 02:30 happens once at +02:00 and again at +01:00.
Both cases break naive code. A "spring forward" wall-clock time has no valid instant to map to; a "fall back" wall-clock time maps to two. Any scheduler that stores local times without an offset will double-book or skip an appointment once a year, and the bug will look like a one-off mystery.
Why UTC is the right internal format
UTC has no transitions: it never shifts, never repeats, and never skips. Store instants in UTC, attach the user's IANA zone, and convert only at the edges — when you render for a human and when you parse what a human typed. Timezone conversion in the middle of your business logic is where the bugs live.
| Do | Do not |
|---|---|
| Store epoch milliseconds or a UTC timestamp | Store a local time string with no offset |
| Store the IANA zone name separately | Store a numeric offset as if it were a zone |
| Convert at render time | Convert on write and store the result |
| Use a library for arithmetic across DST | Add 24 hours to mean "tomorrow" |
Frequently asked questions
Why is there no UTC+8 for my city?
Because offsets are not identities. Asia/Shanghai and Asia/Singapore are both +08:00 today, but their histories differ, and a country can change its rules at any time. The zone name is the stable identifier.
What is the difference between GMT and UTC?
UTC is a time standard maintained by atomic clocks. GMT is a time zone (effectively UTC+00:00 for civil purposes) and, historically, a solar-based one. For programming they are interchangeable at zero offset, but UTC is the term the standards use.
Why does my converted time differ from a colleague's?
Usually because one of you is applying an offset and the other is applying a zone, and the date in question falls on the other side of a DST transition. Compare instants, not wall-clock strings.
Does this need an internet connection?
No. Zone data comes from your browser's own ICU database via Intl, so conversion works offline and nothing is transmitted.
Privacy. Your browser's own time zone is read locally to prefill the form. No request is made, so the times and dates you enter never leave the device.