Time Zone Calculator
The time zone calculator converts one local date and clock time into another selected zone. It is built for a specific workflow: enter the source zone, date, and 24-hour time; choose the target zone; get the converted time, converted date, offset difference, and daylight saving status. That makes it useful for meeting handoffs, flights, webinars, customer support coverage, releases, and deadline checks.
Canonical route and related tasks
The older /calculators/timezone spelling redirects to this canonical page. A conversion here preserves one instant while changing its local clock and calendar representation; it does not measure elapsed time or calculate payroll.
After conversion, you may need a second calculator. Use the time duration calculator to measure elapsed time after both endpoints are in the same zone. Use the shift calculator to turn a converted handoff into a start or end time. Use the time card calculator if converted shifts become weekly payroll hours.
Method and calendar rules
The inputs are a source IANA zone, local date, local time, and target IANA zone. Time uses the 24-hour HH:mm range 00:00–23:59. The source zone’s rule for that date maps the local entry to an instant; the target zone’s rule maps the same instant to a target clock time and date.
The target display is:
The offset difference item is calculated from the time-zone offsets at that same instant:
The sign is retained. A positive result means the target local clock is ahead of the source local clock at that instant. The difference is rounded to the nearest minute and shown as +H:MM or -H:MM. Daylight-saving labels compare the selected instant’s offset with the zone’s seasonal offsets for that calendar year.
Checked example
Enter America/New_York as the source zone, 2026-06-25 as the date, 09:00 as the time, and Europe/London as the target zone. On that date, New York is UTC-4 and London is UTC+1. The offset difference is therefore:
The converted time is 14:00, the converted date is 2026-06-25, and the time difference item is +5:00 hours. Both daylight saving items show in effect. If the same 09:00 New York meeting is converted during a transition week, the answer may differ because the United States and United Kingdom do not always change clocks on the same date.
For a date-line example, convert 23:30 in America/Los_Angeles to Asia/Tokyo. The target time may land on the next calendar date. The result is not adding a meeting length; it is showing the same instant on a clock far to the west or east.
Using the result in practice
When sending a meeting time, include the source time, target time, date, and zone names. “09:00 America/New_York / 14:00 Europe/London on 2026-06-25” is clearer than “9 Eastern / 2 London.” For operations, add UTC as a neutral reference if your deployment tools, logs, or incident reports use it. RFC 3339, a profile of ISO 8601-style timestamps, exists because computers and people need date, time, and offset to be unambiguous.
For travel, remember that airline departure and arrival times are usually printed in local airport time. For payroll or staffing, convert the handoff time first, then document local start and end times with the shift or time card tools. For legal or financial deadlines, verify the jurisdiction’s local rule; a filing deadline may depend on business hours, holidays, or the court’s time zone, not just a mathematical offset.
Edge cases and common mistakes
Daylight-saving transitions create ambiguous and nonexistent local times. During spring-forward, a skipped local time is rejected. During fall-back, choose the earlier or later occurrence explicitly; the calculator enumerates matching instants instead of silently accepting a library default.
Do not use abbreviations as if they were unique. CST can refer to Central Standard Time in North America or China Standard Time. Do not assume a fixed offset for a city that observes daylight saving. Do not ignore the converted date. Finally, do not treat the available city list as a complete database; it is a curated set of common zones backed by IANA names.
Calendar and transition boundaries
The entered date follows the Gregorian calendar, including February 29 in leap years. IANA rules determine each zone’s offset and daylight-saving status for that date. Conversion may cross midnight, a month or year boundary, or the international date line, so the target date is part of the result. Skipped spring-forward times are rejected; repeated fall-back times require the selected earlier or later occurrence.
Sources
- IANA, Time Zone Database — canonical project for location-based time-zone identifiers and rule data.
- IETF, RFC 3339: Date and Time on the Internet — internet timestamp profile based on ISO 8601 conventions.
- BIPM, The International System of Units brochure — official context for the second as the SI base unit used underneath clock calculations.