The offset is a function of the date, not a property of the city
Half the time zone mistakes in circulation come from memorizing a number. New York is UTC-5 in winter and UTC-4 in summer. London is UTC+0 and UTC+1. Paris and Berlin are UTC+1 and UTC+2. Sydney is UTC+10 and UTC+11, but shifted the other way round the calendar because it is in the southern hemisphere, so the US-to-Australia gap is at its widest in the northern winter. Phoenix, Honolulu, all of India, China, Japan, Singapore and most of Africa do not move at all.
What this means practically: a difference you verified in February is not necessarily the difference in July, and a recurring meeting fixed by offset rather than by local time will slide by an hour twice a year. This tool resolves the offset for the specific instant you are converting, which is the only way to get it right without a table of transition dates you would have to maintain.
The weeks when the usual difference is wrong
North America and Europe do not switch on the same day, and that produces two annual windows where the familiar gap is off by an hour. The US and Canada start daylight saving on the second Sunday in March and end it on the first Sunday in November. The EU and the UK run from the last Sunday in March to the last Sunday in October. So for roughly three weeks in March, New York has sprung forward and London has not — the difference is four hours instead of five. For the week between late October and early November it goes the other way: Europe has fallen back and the US has not, giving four hours again.
Australia adds a third pattern, moving in early October and early April. Any standing call that spans two of these regions needs checking in March, October and November, and this is the specific failure that makes people miss meetings they have attended reliably for months.
Abbreviations are worse than useless
EST and EDT are different offsets an hour apart, and most people write EST for both, which means "3 PM EST" in July is ambiguous by an hour. ET at least admits it means whichever is current. IST is India, Ireland and Israel. CST is used for the US Central zone, for China, and occasionally for Cuba. BST is British Summer Time and also Bangladesh Standard Time.
Write the city, or write the UTC offset, or write both: "3 PM New York (UTC-4)". In code, use IANA identifiers — America/New_York, Europe/London — and store instants in UTC, converting to local time only for display. A timestamp stored with a fixed offset is already wrong for any date on the other side of a transition.
Two hours that are not real, and one that happens twice
On the morning daylight saving starts, the local clock jumps from 1:59 to 3:00. The hour in between does not exist in that zone, and a datetime falling inside it is not a valid local time. When it ends, the hour before the change occurs twice — 1:30 AM happens, an hour passes, and 1:30 AM happens again. Every scheduling system has to pick a convention for both, and this tool resolves a nonexistent time forward by consulting the offset that applies after the shift, and takes the first of a repeated pair. If you are writing something where those hours matter — billing, logs, shift handover — the safe approach is to store UTC and never do arithmetic on local wall time at all.
Questions people ask
Is the time I type interpreted in the reference zone or in my own?
In the reference zone you selected. Set the reference to London, type 14:00, and you are converting 2 PM London time regardless of where you are sitting. Leave the field blank and it converts the current instant instead, in which case the reference zone only affects what the differences are measured against.
Does this use fixed offsets or real time zone data?
Real data. Every conversion goes through Intl.DateTimeFormat with an IANA zone name, which resolves against the tz database shipped with your browser for the instant in question. That is why daylight saving, half-hour offsets and zones that have changed their rules all come out right without any special handling here.
How does it know whether daylight saving is in effect?
It compares the zone offset on January 1 with the offset on July 1 of the same year. If they match, the zone does not observe daylight saving. If they differ, the zone is on daylight saving whenever its current offset equals the larger of the two. This is reliable for every zone that has one transition pair per year, which is all of them today; it would not correctly describe a zone with a more exotic schedule, and it reports based on the offset rather than on what the local law calls it.
My city is not listed.
Zones cover regions, not cities. Boston, Atlanta, Miami and Toronto share New York. Dallas, Houston, Chicago and Winnipeg share Chicago. Seattle, San Francisco and Vancouver share Los Angeles. Amsterdam, Madrid, Rome, Vienna and Stockholm all match Paris. Hong Kong and Taipei match Shanghai. Any city on the same rules gives an identical answer.