Time Zone Calculator
A calendar invite can fail even when everyone agrees on “9:00”. The Time Zone Calculator turns that fragile local time into the same instant on another clock, using the date, source zone, and target zone together. It is built for calls across offices, release windows, flight handoffs, remote classes, and any plan where daylight saving time can move the answer by an hour.
Time-zone conversion starts with an instant
Civil time is local: each region labels the same moment with its own date, hour, offset from UTC, and daylight saving rule. This calculator accepts a source time in 24-hour HH:mm format, combines it with the selected calendar date, interprets that local timestamp in the source IANA time zone, and then formats the identical instant in the target IANA time zone. The result panel shows the converted time, converted date, offset difference, and daylight saving status for both zones.
The current form offers UTC, New York, Los Angeles, Chicago, London, Paris, Tokyo, Shanghai, Dubai, Sydney, and Auckland. Those are real IANA zones behind the friendly labels: for example, New York means America/New_York, not a vague “Eastern time” abbreviation. If you need to measure elapsed hours after the conversion, pair the result with the time duration calculator. If you are assigning shifts after a global handoff, the shift calculator and time card calculator help turn converted times into work-hour records.
Method used by the calculator
The underlying computation is not a simple table of offsets. The form uses fromZonedTime to convert the entered source-zone wall time into a UTC-based JavaScript Date, then uses formatInTimeZone to display that instant in the target zone. The displayed offset difference is calculated from the two zone offsets at that instant:
That date-specific method matters because daylight saving time does not begin and end everywhere on the same day. London and New York, for example, can be four hours apart during parts of March or October even though they are often five hours apart. Tokyo, Shanghai, and Dubai do not follow the same seasonal pattern as New York or Paris. A fixed offset such as UTC-5 or UTC+1 is safe only when you already know it applies on the selected date.
For written timestamps, ISO 8601 and RFC 3339 encourage unambiguous date-time forms with numeric offsets, such as 2026-06-25T14:00:00+01:00. The calculator displays a friendly local time, but when you copy the result into a system log, deployment ticket, or contract deadline, include the date, zone name, and preferably a UTC timestamp.
Worked example: New York to London
Suppose a product team in New York schedules a release review for 09:00 on 2026-06-25 and needs the London time. Choose New York (EST/EDT) as the source zone, enter 09:00, set the date to 2026-06-25, and choose London (GMT/BST) as the target zone.
The calculator treats 2026-06-25T09:00:00 as a local New York time. On that date, New York is observing daylight saving time at UTC-4 and London is observing British Summer Time at UTC+1. The offset difference is therefore:
The result is 14:00 on 2026-06-25, with a time difference of +5:00 hours. Both daylight saving indicators report in effect. In a project note, write it as “09:00 America/New_York / 14:00 Europe/London on 2026-06-25” rather than “9 Eastern” or “2 London”.
How to use the answer in real life
For meetings, send the converted date and time in the recipient’s local zone and include UTC if the meeting is operationally important. For travel, remember that tickets and hotel confirmations usually show local time at each airport or property, not your home zone. For software releases, convert the human schedule into UTC before entering cron jobs, maintenance windows, or incident timelines. For finance and legal deadlines, check the governing document: a due date can depend on local business hours, holidays, and jurisdiction, not only on the clock conversion.
If you are comparing a converted timestamp with a calendar interval, use the age calculator only for date-based age questions and the time duration calculator for exact elapsed hours. For astronomical or IT day counts that intentionally avoid local time zones, the julian date calculator may be the better tool.
Edge cases and common mistakes
Ambiguous fall-back hours are the hardest case. When clocks repeat an hour at the end of daylight saving time, a local time such as 01:30 can occur twice. Nonexistent spring-forward times are also tricky because the clock jumps over them. The form relies on the date-fns-tz library’s interpretation for those rare local timestamps; for travel, medical, legal, or financial records, verify the official local rule.
Avoid converting with abbreviations alone. CST, IST, and BST are overloaded globally. Avoid assuming that neighboring countries change clocks together. Do not ignore the converted date, especially near midnight or the international date line. Finally, remember this legacy timezone page uses the canonical time-zone form but with a limited city list, so it is not a complete world time-zone database.
Sources
- IANA, Time Zone Database — canonical source for location-based time-zone identifiers and rule updates.
- IETF, RFC 3339: Date and Time on the Internet — profile of ISO 8601-style timestamps for internet protocols.
- BIPM, The International System of Units brochure — official SI context for seconds and time measurement.