A 9:00 AM July meeting in New York is 1:00 AM the next day in Auckland, because Eastern Daylight Time and New Zealand Standard Time sit 16 hours apart.
Results computed in your browser.
A 9:00 AM call between New York and London isn't a fixed number of hours apart all year. For a few weeks each spring and fall, the gap changes by an hour, because the US and Europe don't start or stop daylight saving on the same date. That's the entire reason this tool asks for a date, not just a time.
New York sits at UTC minus 5 in winter and UTC minus 4 once daylight saving starts. London sits at UTC plus 0 in winter and UTC plus 1 in summer. Converting 9:00 AM New York to UTC, then to London's offset for that date, is how the tool avoids the trap of just adding "5 hours" as a fixed rule that quietly breaks twice a year.
| Zone | Standard offset | Daylight offset |
|---|---|---|
| UTC | UTC+0 | UTC+0 (no DST) |
| New York (Eastern) | UTC-5 | UTC-4 |
| Los Angeles (Pacific) | UTC-8 | UTC-7 |
| London | UTC+0 | UTC+1 |
| India (IST) | UTC+5:30 | UTC+5:30 (no DST) |
| Tokyo | UTC+9 | UTC+9 (no DST) |
India Standard Time runs at UTC plus 5:30, a half-hour offset that most of the world doesn't share. Converting between India and nearly any US zone lands on a half hour rather than a clean hour boundary, which is worth knowing before you schedule a call and wonder why the result looks odd.
Cross enough zones and the day changes, not just the hour. It can already be tomorrow in Sydney while Los Angeles is still on today's date, a gap that runs 18 hours or more. 8:00 PM Monday in Los Angeles lands in the early afternoon of Tuesday in Sydney. The converted date shown above exists precisely so a scheduled call doesn't quietly land on the wrong day.
Arizona and Hawaii, most of Asia, and the UTC reference itself never observe daylight saving, so converting to or from any of them removes the seasonal variable entirely; the offset is the same in July as it is in January. Everywhere else, the tool reads the IANA time zone database bundled with your browser for the date you picked, which is the same database that tracks each zone's historical rule changes, not just today's.
Sources: IANA Time Zone Database, NIST Time and Frequency FAQ.
Because the US and Europe start and end daylight saving on different dates each year. For a few weeks each spring and fall, the gap between, say, New York and London is temporarily one hour different from the rest of the year.
India Standard Time sits at UTC plus 5:30, a half-hour offset. Most US zones sit on whole-hour offsets, so any conversion between the two lands on a half hour, never a clean hour boundary.
No, that's expected once zones are far enough apart. It can already be tomorrow in Sydney while it's still today in Los Angeles, an 18-hour-plus gap that regularly pushes a converted time onto a different calendar date.
It uses the IANA time zone database bundled with your browser, which tracks each zone's rules for the specific date you enter, including past changes to when DST started or ended in previous years.
Arizona and Hawaii within the US, plus most of Asia and the entire UTC reference, stay on one offset year round. Converting to or from any of those removes one seasonal variable from the calculation.