“Can you do 3 p.m. my time?” is a complete sentence and an incomplete instruction. It omits the date, the zone and the offset, and any one of those can move the meeting by an hour or a day. A time zone converter works only when the input identifies a place and an instant, not just a clock reading.
This guide is part of the age calculator guide. It explains why offsets change, converts several 2026 meetings through UTC, and lists the daylight saving cases that break otherwise careful schedules. The examples use IANA zone names so the rules stay attached to the place.
An offset is a rule, not a constant
UTC−5 is not “the New York offset”. It is the offset New York uses while standard time is in effect. From March 8 to November 1, 2026, New York uses UTC−4 under daylight saving time. London uses UTC+0 in winter and UTC+1 from March 29 to October 25. Sydney moves in the opposite direction on the calendar because it is in the southern hemisphere: daylight time began there on October 4, 2026 and ends on April 4, 2027.
Because the switch dates differ by country, the gap between two cities is not stable. New York and London are normally five hours apart. Between March 8 and March 29, 2026, New York has already sprung forward while London has not, so the gap is four hours. The same four-hour gap returns between October 25 and November 1, when London has fallen back and New York has not. A converter that stores “New York is five hours behind London” will be wrong during both windows.
Abbreviations make the problem worse. EST and EDT are reasonably specific, but CST can mean US Central, China Standard or Cuba Standard. IST can mean India Standard, Irish Standard or Israel Standard. Use IANA identifiers such as America/New_York, Europe/London, Asia/Kolkata and Australia/Sydney. The identifier carries the full rule set, including historical changes and future scheduled transitions.
India is a useful reminder that “no daylight saving” is not the same as “never changes”. India currently observes UTC+5:30 without a seasonal shift, but the converter should still resolve the zone rule for the date rather than hard-code a permanent offset. Historical dates and future legislation can differ from the current rule.
Converting through UTC, with the arithmetic shown
Convert the source local time to UTC, then convert UTC to the target. The two steps keep the signs straight and make the date rollover visible.
March 10, 2026, 15:00 in New York to Tokyo. New York is on EDT at UTC−4, so 15:00 + 4 hours = 19:00 UTC. Tokyo is on JST at UTC+9, so 19:00 + 9 hours = 28:00, which is 04:00 on March 11. The target date is one day later than the source date.
December 15, 2026, 15:00 in New York to Tokyo. New York is on EST at UTC−5, so 15:00 + 5 = 20:00 UTC. Add 9 hours for Tokyo: 29:00, or 05:00 on December 16. The local clock time is the same as in March, but the conversion is one hour later because New York’s offset changed.
March 10, 2026, 15:00 in London to New York. London is still on GMT at UTC+0, so the UTC time is 15:00. New York is on EDT at UTC−4, so subtract 4 hours: 11:00 in New York. The four-hour gap is temporary. On April 10, London is on BST at UTC+1, so 15:00 London is 14:00 UTC and 10:00 in New York, a five-hour gap.
| Source local time | UTC | Target zone | Target local time | Date shift |
|---|---|---|---|---|
| 2026-03-10 15:00 America/New_York (UTC−4) | 19:00 | Asia/Tokyo (UTC+9) | 2026-03-11 04:00 | +1 day |
| 2026-12-15 15:00 America/New_York (UTC−5) | 20:00 | Asia/Tokyo (UTC+9) | 2026-12-16 05:00 | +1 day |
| 2026-03-10 15:00 Europe/London (UTC+0) | 15:00 | America/New_York (UTC−4) | 2026-03-10 11:00 | same day |
| 2026-04-10 15:00 Europe/London (UTC+1) | 14:00 | America/New_York (UTC−4) | 2026-04-10 10:00 | same day |
| 2026-10-22 09:00 America/New_York (UTC−4) | 13:00 | Asia/Kolkata (UTC+5:30) | 2026-10-22 18:30 | same day |
| 2026-10-22 09:00 America/New_York (UTC−4) | 13:00 | Australia/Sydney (UTC+11) | 2026-10-23 00:00 | +1 day |
The last row is the one people miss. Sydney is 15 hours ahead of New York on that date, so a 09:00 call in New York is midnight at the start of the next day in Sydney. The date changes even though the conversion is only a few hours of arithmetic.
DST gaps, repeated hours and mismatched switch dates
Spring forward creates times that do not exist. On March 8, 2026, New York clocks jump from 02:00 to 03:00, so 02:30 is not a valid local time. A scheduler that accepts it must either reject the input or shift it forward to 03:30. On March 29, 2026, London does the same at 01:00, so 01:30 is missing there.
Fall back creates times that exist twice. On November 1, 2026, New York clocks move from 02:00 back to 01:00, so 01:30 occurs once in EDT and again in EST. The two occurrences are an hour apart in UTC. An invitation that says “01:30” without an offset is ambiguous; one of the two will be wrong for at least one participant.
Mismatched transition dates create a quieter problem. A weekly 15:00 New York–London call is five hours apart for most of the year, four hours apart from March 8 to March 29, and four hours apart again from October 25 to November 1. If the series is stored as “15:00 New York” and “20:00 London”, the London time is wrong during those windows. If it is stored as a UTC instant, the local times shift automatically but the wall-clock hour changes for both sides.
Decide which promise the meeting makes. “Same local time every week” preserves the clock reading and lets the UTC instant move. “Same absolute instant every week” preserves the UTC time and lets the local clock move. Both are valid; a series that silently mixes them is not.
Date rollover and the international date line
Date rollover is not limited to the date line. Any conversion that pushes the local time past midnight changes the date. New York to Tokyo at 15:00 produces 04:00 the next day. New York to Sydney at 09:00 produces midnight the next day. A meeting at 23:00 in Los Angeles to London lands at 07:00 the next morning when the usual eight-hour gap applies.
The international date line adds a full-day difference between some pairs. Auckland, at UTC+13 during southern summer, is 17 hours ahead of New York at UTC−4. A 09:00 New York call on October 22 is 02:00 on October 23 in Auckland. Tokelau and Samoa sit at UTC+13; American Samoa sits at UTC−11, so the two Samoas are 24 hours apart despite being close neighbours.
When the output date differs from the input date, say so explicitly in the invitation. “March 10, 15:00 New York / March 11, 04:00 Tokyo” is clearer than “15:00 New York” with a separate note that Tokyo is ahead. The date is part of the conversion, not an afterthought.
A scheduling checklist that survives transitions
- Name the zones, not the abbreviations. Use America/New_York and Asia/Tokyo. Add the offset at the meeting instant as a human-readable check.
- Convert through UTC. Write the UTC time down. It is the one value that does not change when a government adjusts a rule.
- Check both ends of the meeting. A call that starts before a transition and ends after it can span two clock hours while only one hour of real time passes, or the reverse.
- Check the date on both sides. If the target date differs, include it in every message and calendar entry.
- Test transition weekends. March 8, March 29, October 25 and November 1, 2026 are the dates to inspect for US, UK and EU participants. Australia’s dates are separate.
- State the recurrence rule. “Every Tuesday at 15:00 New York” and “every Tuesday at 19:00 UTC” behave differently after a transition. Pick one and write it down.
- Ask a second person to read the invitation. A local participant will catch a wrong offset faster than any amount of arithmetic.
For logs and APIs, store the UTC instant and the IANA zone separately. The instant answers “when did it happen”; the zone answers “what time was it for the user”. Storing only a local string loses the offset, and storing only an offset loses the zone rule. The Unix timestamp guide covers the integer side of that pair, and the date difference guide covers the calendar side.
Using the time zone converter
Pick the date and time, then choose the source and target zones by name. Read three things: the converted local time, the date on each side, and the offset in effect. If the tool shows a UTC row, compare it with the arithmetic above; that row is the anchor that makes the rest checkable.
- Enter 2026-03-10 at 15:00 with America/New_York as the source and Asia/Tokyo as the target. Confirm 04:00 on March 11.
- Change the date to 2026-12-15 and confirm 05:00 on December 16, one hour later than the March result.
- Convert 2026-03-10 15:00 Europe/London to America/New_York and confirm 11:00, not 10:00.
- Convert 2026-10-22 09:00 America/New_York to Australia/Sydney and confirm 00:00 on October 23.
If a result looks an hour off, check the transition weekend first. If it looks a day off, check the date line and the target date. If it looks several hours off, check whether the source zone was entered with the right city, not just the right country.