How a wall-clock time becomes an instant
A time such as "3 PM in New York" is only a label until a zone and a date pin it to a single moment on the UTC timeline. The converter does that in two steps. First it asks the browser's Intl.DateTimeFormat what the offset of the chosen zone is on either side of that day, then keeps only the offsets that really apply to the typed time, which handles a daylight saving change on the day itself. The resulting instant is then formatted separately for each target zone with the same Intl machinery. The offsets come from the IANA Time Zone Database (the "tz database"), which names zones by region and city, such as Europe/London or Asia/Kolkata, rather than by abbreviations like EST or IST that are ambiguous. The "From" zone starts as the zone your browser reports (with older aliases such as Asia/Calcutta matched to the name in the list); the date defaults to 16 June 2026 until you change it.
Worked example
Take 12:00 noon on 16 June 2026 in New York. In June the city is on daylight time (UTC-4), so the instant is 16:00 UTC. That same moment is 17:00 in London (British Summer Time, UTC+1) and 01:00 on 17 June in Tokyo (UTC+9, which does not use daylight saving). The row for Tokyo shows the next calendar date, which is correct and not a bug.
Daylight saving traps
| Zone | 2026 clocks forward | 2026 clocks back |
|---|---|---|
| US and Canada (most areas) | 8 March | 1 November |
| UK and EU | 29 March | 25 October |
Because the two regions change on different weekends, the usual 5-hour gap between New York and London shrinks to 4 hours for about three weeks in March and for one week in late October and early November. Scheduling a recurring meeting across that window is a common source of "why is everyone an hour early" mistakes.
Nonexistent and ambiguous local times
On the day clocks jump forward, some local times never happen (2:30 AM on 8 March 2026 in New York), and on the day they fall back, other local times happen twice (1:30 AM on 1 November 2026). The datetime field cannot express which occurrence you mean, so the tool applies one rule everywhere and tells you when it did. A nonexistent time is moved forward by the length of the gap: 2:30 AM on 8 March 2026 in New York becomes 3:30 AM Eastern Daylight Time (7:30 UTC), and 1:30 AM on 29 March 2026 in London becomes 2:30 AM British Summer Time. An ambiguous time uses the earlier occurrence: 1:30 AM on 1 November 2026 in New York is the daylight one (5:30 UTC), and 1:30 AM on 25 October 2026 in London is the BST one (00:30 UTC). A short note appears under the fields whenever either rule was applied. If you meant the later occurrence, enter a time just after the changeover and compare the rows.
Other limits
- The results show date and time but no offset or abbreviation, so the zone name beside each row is your only label.
- The zone list is whatever your browser's
Intl.supportedValuesOfreturns, which uses canonical names. Some browsers omit the plainUTCentry, so the tool adds UTC (at the top), your own zone and the default zones when the browser leaves them out. Older browsers fall back to a list of 17 major zones. - Governments change rules, sometimes with little notice. Your browser's bundled tz data can lag behind, so for far-future dates in unstable regions treat the result as a best estimate.
To turn the instant into a number for code, use the timestamp converter, and to measure the gap between two dates use date difference.