Timezone Calculator
Convert time between IANA timezones with proper DST handling. Powered by Intl.
Converting a time between two zones
Pick the source zone, the target zone and a time, and read the result. The everyday uses are scheduling across a distributed team and checking that a feature which displays times, a booking, a delivery window, a maintenance banner, shows the right thing to a user somewhere else.
The detail that catches people out is that an offset is not a property of a place, it is a property of a place at a moment. New York is five hours behind UTC in January and four hours behind in July. Any test that hard-codes an offset will pass for half the year and fail for the other half, usually on a day when nobody changed anything.
Daylight saving transitions are where the bugs are
Twice a year most zones shift, and each direction breaks software differently. These two cases belong in the test plan of anything that schedules, bills or reports by time:
| Transition | What happens | What breaks |
|---|---|---|
| Spring forward | An hour never exists: the clock jumps from 01:59 to 03:00 | A job scheduled at 02:30 never runs; a date parser rejects a valid-looking time |
| Fall back | An hour happens twice: 01:30 occurs on both sides of the shift | A job runs twice; ordering by local time scrambles; a duration comes out negative |
Two more properties make it harder. Not every zone shifts on the same date: Europe and North America change on different weekends, so for a couple of weeks each year the offset between London and New York is not what anyone expects. And the southern hemisphere shifts in the opposite direction, so a system that assumes summer means later has it backwards for Sydney.
Store UTC, store the zone, never store the offset
The rule that prevents most timezone defects: store the instant in UTC, and where a future local time matters, store the IANA zone identifier such as Europe/Kyiv alongside it. Storing an offset like +02:00 instead looks equivalent and is not, because the offset for that zone will be different in six months and the stored value has no way to know.
This matters for recurring events specifically. A meeting set for nine every Monday morning means nine local, and the underlying UTC instant must change when the zone shifts. A system that converted once to UTC and stored only that will silently move the meeting by an hour twice a year.
Timezone values worth testing with
Asia/Kolkata: a half-hour offset, which breaks code that assumes whole hours.Asia/Kathmandu: a forty-five minute offset, which breaks it further.Pacific/Kiritimati: the furthest ahead, useful for finding date rollover errors.Pacific/Niue: far behind, where it is still yesterday for most of the world.Australia/Sydney: southern hemisphere, so daylight saving runs opposite to Europe.UTCitself: the control case that should always be correct.- A zone that does not observe daylight saving at all, such as
Asia/Tokyo.
Testing a feature that displays times
- Set your machine or browser to a different timezone and reload: many display bugs appear immediately.
- Check a time near midnight, where a conversion can change the displayed date as well as the hour.
- Check a date on both sides of a daylight saving transition in at least one zone.
- Confirm the zone is labelled in the interface. A bare time with no zone is ambiguous and is a defect in any product with users in more than one country.
- Compare what the API returns with what the screen shows, and identify which layer did the conversion.
Conversions run in your browser using the timezone data the browser ships, so nothing is sent anywhere.
Frequently asked questions
Why does the offset between two cities change during the year?
Because each zone observes daylight saving on its own schedule, and some do not observe it at all. The offset between London and New York is usually five hours but is four for the short period when one has shifted and the other has not.
Should I store dates in UTC or local time?
Store the instant in UTC. Where a future local time matters, also store the IANA zone identifier so the correct offset can be recomputed later. Storing a fixed numeric offset is the common mistake, because the offset is only valid for the moment it was captured.
What happens to a job scheduled at 02:30 on the night the clocks go forward?
That local time does not exist, so depending on the scheduler the job is skipped, runs at 03:30, or throws. All three are defensible and all three surprise someone, which is exactly why it needs an explicit test and a documented expected result.
Are all timezone offsets whole hours?
No. India is five and a half hours ahead of UTC, Nepal five and three quarters, and parts of Australia use half-hour offsets. Code that stores an offset as an integer number of hours is broken for a large population.
What is the difference between GMT and UTC?
In everyday use they are treated as the same, but GMT is a timezone that some regions observe while UTC is a time standard that never changes for daylight saving. In software, prefer UTC, and note that the United Kingdom is on GMT in winter and British Summer Time in summer, so GMT is not a synonym for UK local time.
Why is the date wrong rather than just the time?
Because a conversion across midnight moves the date too. A meeting at 23:00 in Kyiv is on the previous day in New York. Any report grouped by day needs to state which timezone defines the day, or two people will legitimately see different totals.