Time Zone Calculator

target wall clock = source wall clock − source UTC offset + target UTC offset; offset difference = target offset − source offset; day shift = target date − source date

date

The calendar day at the source, written as YYYY-MM-DD. It is the day over there, not the day where you are reading this

time

The wall clock at the source, as HH:MM or HH:MM:SS in 24-hour form. Seconds may be left off; they are always shown in the result

fromZone

The zone the time you typed belongs to. One of 22 IANA zones, each labelled with its city rather than its offset, because the offset is a property of the moment and not of the place

toZone

The zone to convert into. The same 22 zones as the source list

toTime

The wall clock at the target zone, always with seconds. This is the headline result

toDate

The calendar date at the target zone, which is not always the date you typed — that is the whole point of the day shift

toWeekday

The day of the week at the target zone, given as a number from 0 (Sunday) to 6 (Saturday)

fromOffset

How far the source zone is from UTC at the resolved instant, written as UTC±HH:MM

toOffset

How far the target zone is from UTC at the same instant. Both offsets are read at the converted moment, so both include daylight saving if it is in force there

offsetDifference

Target offset minus source offset, in hours. Negative means the target is behind the source

dayShift

−1, 0 or +1: whether the target date is the day before, the same day, or the day after the one you entered

Use it whenever two places are involved and a clock has to be trusted: booking a call across an ocean, checking whether a flight lands on the same day it took off, reading a server log written in UTC, or working out why a friend's "Sunday morning" is your Sunday evening. The day shift is the part people get wrong by hand, because it is not a fixed property of the pair of cities — the same two zones differ by 12 hours in January and 11 in July. This page converts an instant you already have; it does not tell you which zone a place is in (the lists are fixed at 22 zones), and it says nothing about travel times, flight durations or appointment reminders.

1. Shanghai noon to New York — the previous day

   1. Shanghai is UTC+08:00 in January, so noon there is 04:00 UTC on 15 January
   2. New York is on EST, UTC−05:00, so 04:00 UTC reads as 23:00 on the clock there
   3. 23:00 is behind midnight, which puts the date at 14 January — one day before the one entered, and the day shift says so with −1
   4. 14 January 2026 is a Wednesday, so the weekday number is 3
   5. The two offsets differ by −13 hours: 08:00 − (−05:00) is 13 hours, and the target is the one further west

   The default state of the calculator, and the case that surprises people most: a message sent at lunchtime in Shanghai reaches New York on the previous calendar day. Doing this by hand with a single "Shanghai is 12 or 13 hours ahead" rule is where the mistake creeps in — the answer here is 13, but in July it would be 12, because New York is on daylight time and Shanghai is not.

2. A wall clock that does not exist: New York, 8 March 2026, 02:30

   1. Clocks in New York move forward at 02:00 local on this date, so 02:00 becomes 03:00 and the half hour from 02:00 to 03:00 never happens
   2. The typed 02:30 therefore does not exist. The page reads it the way the IANA rules prescribe for a gap: shift it forward, giving 03:30 EDT
   3. 03:30 on 8 March 2026 is a Sunday, hence weekday 0
   4. Because the resolved instant already sits in EDT, the source offset printed is UTC−04:00 — not the UTC−05:00 that 02:30 would have carried the day before
   5. Shanghai is UTC+08:00, twelve hours ahead of EDT, so 03:30 becomes 15:30 the same day

   The offset printed beside a typed time can look wrong until you see why: 02:30 in New York is a UTC−05:00 clock reading in winter, but this particular 02:30 falls in the gap after the switch, so the instant it resolves to is an EDT one and reports UTC−04:00. The page reads gaps and overlaps the same way the IANA time zone database prescribes, and never refuses the input — so the number is always produced, and this is the case worth reading twice.

3. Both ends on daylight time: London to Los Angeles on 4 July

   1. In July London runs on BST, UTC+01:00, so 09:30 there is 08:30 UTC
   2. Los Angeles runs on PDT, UTC−07:00, so 08:30 UTC is 01:30 on the clock there
   3. The offsets differ by 8 hours, not the 8 hours people expect in winter either — but the two are different 8s: in January London is UTC+00:00 and Los Angeles UTC−08:00
   4. Both offsets printed include their daylight saving, which is why the source reads UTC+01:00 rather than UTC+00:00
   5. The date is unchanged, so the day shift is 0 — and 4 July 2026 is a Saturday, weekday 6

   Answering this with the standard offsets (0 and −08:00) gives the same 8-hour difference and the same clock time, which is exactly why the error is easy to miss here and shows up on the dates either side of a transition instead. Both zones switching in opposite directions during the same week of March is when a fixed-offset rule goes wrong by a full hour.

4. New Year in Auckland, still last year in UTC

   1. Auckland is on NZDT in January, UTC+13:00, so midnight there is 11:00 UTC on 31 December 2025
   2. Converting to UTC therefore crosses both a day boundary and a year boundary at once
   3. The target date is 31 December 2025, and the day shift of −1 is computed by subtracting day numbers rather than by comparing date strings
   4. 31 December 2025 is a Wednesday, weekday 3
   5. The offset difference is −13 hours: the target, UTC, is the one further west

   The day shift is not simply "west is yesterday". Here −13 hours crosses midnight; the same −13 hours between Shanghai and New York also lands on the previous day, while a −5 hour difference from London to New York does not. The weekday is reported for the target date, which is why it says Wednesday when the date entered was a Thursday.

The calculator covers 1970 to 2100 and 22 time zones, not every zone the IANA database knows about. The window is deliberate: before 1970 the database records what local mean time a place actually kept — Shanghai was UTC+08:06, Monrovia used an offset with seconds in it — and answers like that are correct but read as bugs. Ambiguous and non-existent wall clocks are resolved the way the IANA rules prescribe (shift forward across a spring-forward gap, take the earlier of the two readings across an autumn overlap) rather than being rejected; the page does not warn you that it happened, so the dates around a transition are worth checking against the offsets shown. No zone is inferred from the place name you type, because there is nothing to type into: both lists are fixed. The page does not know which zone your own device is in, does not do durations or flight times, and does not include leap seconds — UTC has none, which is separate from the leap seconds that get added to UTC itself.

What is the time difference between two cities?

The time difference between cities is not a fixed number, and the offset difference this page prints is the one in force on the date you entered. Two zones can differ by 13 hours in January and 12 in July because one of them observes daylight saving time and the other does not. So the answer to "what is the difference between Shanghai and New York" has to be asked with a date attached, which is why the date field is part of the question here rather than an optional extra.

How do I work out a meeting time across time zones?

Put the meeting in the zone it was proposed in, then convert it to each other zone in turn. For a meeting time across time zones the useful number is usually the day shift rather than the hour: a call at 09:00 in London is 18:00 in Tokyo the same day, but 04:00 in New York, and the 04:00 is the one that decides whether the invitation is reasonable. Because the page reports the weekday and the date as well, you also see when a proposal has landed on the other side's weekend.

Does it apply daylight saving time automatically?

Yes, for both zones, and for the exact date rather than for today. Daylight saving time is not a property of a zone but of a moment: the offsets printed are the ones the IANA rules give for the instant being converted, so a January date and a July date between the same two zones can come out one hour apart. Nothing is assumed about the current date, which means a result computed for next March already includes the transition next March.

Why is the UTC offset sometimes not the one I expected?

Because the offset shown belongs to the instant the input resolved to, not to the wall clock you typed. On the day clocks move forward, the hour that was skipped does not exist, and a time typed inside that hour is read as the moment just after it — so a 02:30 entered for New York on a March transition day reports UTC−04:00 (EDT) and not the UTC−05:00 that 02:30 carried the day before. Both readings are of the same instant; only one of them is the offset in force then.

What day is it there when it is Wednesday here?

It depends on the hour as well as the zones, which is why this page asks for both. Cross the date line eastward and you gain a day; convert westward across enough hours and you lose one. The day shift field answers it directly with −1, 0 or +1, and the weekday field names the day at the destination, so you can tell whether the other side has already reached the day you are asking about.

• IANA Time Zone Database — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — IANA — the source for the 1970-01-01 accuracy window this page states
• Temporal documentation — Time zone handling — TC39 — describes the 'compatible' disambiguation rule this page follows