How the conversion works
The converter takes a date, a time, and a source time zone, and resolves them to a single instant in time. That instant is then formatted in each target zone you have selected. Because everything runs through one absolute instant, the results are internally consistent: all the displayed times refer to the same moment, just described from different places.
Resolving a local date and time to an instant requires knowing the source zone's offset at that moment, which itself depends on the date. The tool handles this by making an initial estimate, checking the resulting offset, applying it, and checking again, which converges on the correct instant including across daylight saving transitions.
Conversions use the IANA time zone database through the browser's own internationalization support, which is why zone names look like Europe/London rather than GMT or BST. That naming is deliberate: a region identifier carries the full history and future rules for that place, while an abbreviation only describes one offset at one time of year.
A worked example across four zones
Take 15 March 2026 at 09:00 in America/New_York. US daylight saving time began on 8 March 2026, so New York is on Eastern Daylight Time at UTC-4. The instant is therefore 13:00 UTC.
Europe/London on that date is still on Greenwich Mean Time, because British Summer Time does not begin until 29 March 2026, so London shows 13:00 on the same day. Asia/Tokyo is UTC+9 year round with no daylight saving, so it shows 22:00 on 15 March.
Australia/Sydney is on Australian Eastern Daylight Time at UTC+11, since its summer time does not end until 5 April 2026. Adding 11 hours to 13:00 UTC gives 00:00 on 16 March, a different calendar date from the source. This is why the tool shows the date alongside the time in every zone: the date change is easy to miss and is the usual cause of a meeting booked on the wrong day.
Daylight saving time and why offsets move
Roughly a third of the world observes some form of daylight saving, and those that do change on different dates. The United States switches on the second Sunday in March and the first Sunday in November. The European Union switches on the last Sunday in March and the last Sunday in October. Australia and New Zealand, being in the southern hemisphere, run the opposite way, with summer time spanning the northern winter.
Between the US and European transition dates there is a two to three week window each spring and autumn when the usual gap between, say, New York and London is one hour different from normal. A recurring meeting scheduled by fixed offset rather than by zone will drift during those weeks. Converting for the specific date, which is what this tool does, avoids the problem.
Many zones do not observe daylight saving at all, including Japan, India, China, and most of Africa and Southeast Asia. Some have unusual offsets that are not whole hours: India is UTC+5:30, Nepal is UTC+5:45, and parts of Australia are UTC+9:30. The offset display accounts for these, which is why it shows minutes as well as hours.
Ambiguous and non-existent local times
Daylight saving transitions create two awkward cases. When clocks spring forward, a range of local times simply does not exist: in New York on the transition date, 02:30 never occurs, because 02:00 becomes 03:00. When clocks fall back, a range of local times occurs twice, so 01:30 on that date is genuinely ambiguous and refers to two distinct instants an hour apart.
The converter resolves these by applying its offset-refinement process and settling on one interpretation. That is a reasonable default, but it means a conversion of a non-existent or duplicated local time will produce a definite answer where the question itself had no single answer. If you are scheduling something near a transition, choose a time clear of the changeover.
Zone rules also change by political decision. Countries have shifted offsets, adopted or abandoned daylight saving, and moved transition dates, sometimes with little notice. Conversions for dates far in the future rest on the rules currently in the database, and a future rule change would invalidate them.
Using UTC and reading offsets
UTC is the reference against which every zone's offset is defined, and it does not observe daylight saving. It is the right choice for logs, timestamps, coordination across many regions, and any record that must remain unambiguous later. The tool includes UTC as a selectable zone on both sides of the conversion.
The offset shown next to each result, such as +09:00 or -04:00, is that zone's offset from UTC at that specific instant rather than a permanent property of the zone. Subtracting one displayed offset from another gives the hours difference between those two places on that date, which is often the quickest way to sanity-check a result.
The tool detects your browser's time zone on load and prefills the current date and time, so the first thing you see is your own local moment. The source zone can then be changed to any of the listed regions, and additional target zones added or removed as needed. Zone detection relies on your device's settings, so a device with the wrong zone configured will produce a correct conversion from the wrong starting point.