How to use this time zone converter
Enter a source date and time from 2000 through 2100, then select or type source and destination IANA IDs such as America/New_York and Europe/London. UTC is also accepted. Abbreviations such as CST and raw numeric offsets are not accepted as substitutes for a location. If the source clock repeats, explicitly choose its first or second occurrence. Changing the source date-time or zone resets that choice. Invalid inputs hide all conversion results; no stale offset or converted date remains visible.
How the calculation works
A local clock reading becomes an exact instant only after its date, time zone and any repeated-time ambiguity are resolved. The date matters because a location's UTC offset can change during the year or following a government decision. The converter first interprets the supplied wall clock in its source zone, then represents the same instant in the destination zone. It does not calculate a journey's elapsed duration by subtracting two clock readings taken in different places.
IANA identifiers name regional time-zone histories, not merely current numeric offsets. America/New_York is therefore more useful for a dated conversion than an ambiguous abbreviation such as EST or CST. Some regions share an offset on one date but follow different rules later. The suggestions list common locations, while manual entry supports other IANA IDs recognized by the runtime. UTC is available for a fixed reference. Place names must identify the intended location, not just the nearest city in a different rules region.
To follow the calculation, start with a hypothetical local time of 09:00 on January 15, 2026 in America/New_York. Under the applicable winter rule, its UTC offset is −05:00, so the same instant is 14:00 UTC and 14:00 in Europe/London at offset +00:00. On July 15, 2026, 09:00 in New York instead corresponds to 13:00 UTC and 14:00 in London at +01:00. The clock difference happens to match in these examples, but the UTC offsets do not.
Regions do not necessarily switch daylight saving on the same dates. On March 15, 2026, New York has already advanced to −04:00 while London remains at +00:00, making 09:00 New York correspond to 13:00 London. Reusing a five-hour difference from January would be wrong for that date. Always convert the actual appointment date rather than taking today's offset and applying it to every later event. Recurring meetings may need to be checked separately across transition weeks.
When a clock jumps forward, some local times never occur. In America/New_York on March 8, 2026, 02:30 falls in the skipped interval and cannot identify an instant. The converter reports that the source time does not exist. It does not silently interpret the entry as 03:30 or move it backward to another hour. Choose an existing local time or consult the event organizer's intended schedule. A calendar date can also be skipped by a permanent zone change, not only seasonal daylight saving.
When a clock moves backward, one local reading may occur twice. In America/New_York on November 1, 2026, 01:30 can mean 05:30 UTC at −04:00 or 06:30 UTC at −05:00. The first and second occurrence selectors identify those chronological instants; they are not labels for a universal summer or winter policy. Both candidate UTC values are shown after an ambiguous conversion is resolved, allowing the chosen occurrence and its offset to be recorded with the result.
Not all offsets or clock changes are whole hours. Asia/Kolkata uses a half-hour offset, Asia/Kathmandu uses a quarter-hour offset relative to whole hours, and Australia/Lord_Howe has seasonal transitions of thirty minutes under the relevant rules. The converter uses zone rules rather than rounding offsets to an hour or assuming every repeated interval lasts sixty minutes. Calendar dates can also differ across the destination boundary. The output states whether the destination date is the same, earlier or later than the source date.
Conversions use the time-zone data installed in the browser or server runtime through a Temporal-compatible implementation. This page does not download a live database or guarantee that every device has the latest government rule change. Browser and operating-system updates can affect results, particularly for future dates. The supported source-date range is 2000–2100; this is not a historical chronology or a guarantee that distant-future legislation is known. For important appointments, retain the named zones, date, UTC instant and explicit offsets, and reconfirm with the authoritative schedule.
Formulas
From local time to UTC
From UTC to destination
Clock offset difference
Worked examples
Different transition dates
March 15, 2026 at 09:00 in America/New_York corresponds to 13:00 in Europe/London under the applicable rules. Both locations and the actual date are needed; a fixed five-hour assumption would produce the wrong destination hour.
Resolve a repeated source time
November 1, 2026 at 01:30 in America/New_York has two occurrences: 05:30 UTC at −04:00 and 06:30 UTC at −05:00. Choose explicitly; the destination conversion then represents that selected instant.
Common uses
Coordinate a dated appointment
Compare source and destination clock readings for one meeting instant, including the calendar date and UTC offsets rather than an undated city-to-city difference.
Review a daylight saving transition
Detect skipped times and explicitly resolve repeated source times. Record the chosen UTC instant so a later clock label cannot obscure which occurrence was intended.
Compare fractional offsets
Convert locations with half-hour or quarter-hour offsets without rounding them to a whole-hour time difference. Distinguish date changes from actual elapsed duration.
Accuracy and limitations
Source dates are limited to 2000–2100 in the Gregorian calendar. Resolution uses Temporal and the runtime's installed IANA-compatible zone data. There is no live database fetch, guaranteed release version or leap-second scheduling support.
Government rules may change after publication, and devices can carry different data versions. Confirm consequential travel, legal deadlines or future meetings against an authoritative schedule. The output compares clock representations of one instant, not the time elapsed between two events.
Sources and methodology
These primary references explain the numerical methods and units used here. Review the calculation assumptions and limitations alongside the result.
Frequently asked questions
Why must I enter a date?
UTC offsets can change with daylight saving and legal rule changes. A time-of-day alone is not enough for a reliable regional conversion.
What happens when a local time occurs twice?
The converter asks for the first or second occurrence and shows the candidate UTC instants after resolution. It never chooses one silently by default.
Does it adjust a nonexistent time automatically?
No. A skipped local time is rejected. Enter an existing time or confirm the intended schedule.
Can I use CST or a numeric UTC offset?
Use UTC or a supported IANA location. Abbreviations are ambiguous, and a fixed numeric offset cannot describe a region's dated rules.
Is the time-zone database updated live?
No. Results use the runtime's installed time-zone data. Keep software updated and reconfirm important future appointments when regional rules change.
Are source times saved?
No. Interactive conversion takes place in your browser without sending the entered appointment time to NumUtility.