Time zone converter with DST gap and overlap handling

How to use

1. Type the clock reading in Local date and time as YYYY-MM-DD hh:mm:ss (a T instead of the space is accepted, and so is a fraction of a second). The button next to it fills in the current time in the source zone.
2. Choose the Source zone: the place where that clock reading is true. Use the filter box to narrow the list, then pick from it. Zone names look like America/New_York.
3. Choose Convert to. It starts on the time zone your browser reports.
4. Say what to do with a reading that does not name exactly one instant. If the time does not exist: shift it later by the length of the gap, shift it earlier by the same amount, or reject it. If the time happens twice: use the earlier instant, the later instant, or reject it.
5. Read the result. The page states whether the reading exists once, does not exist or happens twice, shows the resulting instant in the target zone, in UTC and as an epoch number, and, for a skipped or repeated reading, what it did. The 24-hour bar shows the target day with the offset in force across it, so a clock change inside that day is visible.

The conversion itself goes through the instant: the clock reading and source zone are turned into one point on the UTC time-line, and that point is shown in the target zone. If you already have an epoch number, the epoch converter shows it in any zone directly.

Worked examples

Every result printed here is recomputed by an automated test from the same engine as the tool. The zone transitions behind them are also checked against Python's zoneinfo and Go's time package in the tests.

Noon in New York, before and after the US clocks changed

On 8 March 2026 New York's offset changes from -05:00 to -04:00, so the same noon is one hour earlier in UTC the next day, and Jakarta (no daylight saving, always +07:00) sees it move.

The three weeks when New York and London are 4 hours apart

The same 09:00 in New York, converted to London on three dates in 2026:

On 20 March the US is already on daylight time (-04:00) and London is still on standard time (+00:00), so 09:00 in New York is 13:00 in London, not 14:00.

An offset that is not a whole hour

Nepal's offset is +05:45, so noon there is 06:15 UTC. Code that stores an offset as a number of whole hours cannot represent this.

A time in the spring-forward gap

New York skips from 01:59:59 to 03:00:00 on 8 March 2026, so 02:30 never appears. The three choices give three answers, shown here converted to London:

"Shift later" lands on 03:30 New York time (07:30 UTC), "shift earlier" on 01:30 (06:30 UTC); the two differ by exactly the one-hour gap.

Other gaps, all in the same engine:

Lord Howe Island's gap is only 30 minutes long. Gaps are not always at 02:00 either: São Paulo's 2018 change skipped midnight, and Samoa removed a whole day in 2011.

A time in the fall-back overlap

At 02:00 on 1 November 2026 New York's clocks go back to 01:00, so 01:30 happens twice. With the source zone set to New York, the page lists both instants as epoch numbers (the first is the earlier):

The two readings are one hour apart. Other overlaps:

What your language does with the same clock time

The same two questions asked in several languages. The ones marked as executed were run while this page was written, on a machine with the 2026c time zone database, and print exactly what is shown. The JavaScript runs used TZ=America/New_York as the process time zone.

New York 02:30 on 8 March 2026 (does not exist)

// process time zone: America/New_York
console.log(new Date(2026, 2, 8, 2, 30).toISOString());

from datetime import datetime, timezone
from zoneinfo import ZoneInfo
d = datetime(2026, 3, 8, 2, 30, tzinfo=ZoneInfo("America/New_York"))
print(d.isoformat())
print(d.astimezone(timezone.utc).isoformat())

loc, _ := time.LoadLocation("America/New_York")
d := time.Date(2026, 3, 8, 2, 30, 0, 0, loc)
fmt.Println(d.Format(time.RFC3339))
fmt.Println(d.UTC().Format(time.RFC3339))

New York 01:30 on 1 November 2026 (happens twice)

// process time zone: America/New_York
console.log(new Date(2026, 10, 1, 1, 30).toISOString());

from datetime import datetime, timezone
from zoneinfo import ZoneInfo
ny = ZoneInfo("America/New_York")
for fold in (0, 1):
    d = datetime(2026, 11, 1, 1, 30, tzinfo=ny, fold=fold)
    print(fold, d.isoformat(), d.astimezone(timezone.utc).isoformat())

loc, _ := time.LoadLocation("America/New_York")
d := time.Date(2026, 11, 1, 1, 30, 0, 0, loc)
fmt.Println(d.Format(time.RFC3339))
fmt.Println(d.UTC().Format(time.RFC3339))

What goes wrong

The usual ways clock times go wrong between zones.

Converting with a fixed offset instead of a zone

"New York is UTC-5" is true until 8 March 2026 and false after it. The two noons in the first worked example show it: the same noon in New York is 17:00 UTC on 7 March and 16:00 UTC on 8 March. A fixed offset is correct for one instant only; a zone name carries the rules.

Assuming the gap between two places is constant

New York and London differ by 5 hours for most of the year, 4 hours between the US change on 8 March and the UK change on 29 March 2026, and again between the UK change on 25 October and the US change on 1 November. A recurring meeting set in one zone moves in the other zone's clock when only one of them changes.

Silently accepting a time that does not exist

Many libraries accept 02:30 on 8 March in New York without complaint and return a plausible instant. As the snippets above show, which instant depends on the library: Python keeps the impossible time and only reveals the shift when you convert, JavaScript shows 03:30, and Go gave 01:30. If the time came from a person, the safest course is to ask them; this tool's "reject" option exists for that.

Mixing up which side of the overlap is meant

A log line or a booking that says only "01:30" on 1 November in New York is ambiguous by an hour. Store the offset with it (-04:00 or -05:00) or store the instant.

Zone abbreviations

"IST" means India Standard Time, Irish Standard Time or Israel Standard Time depending on who wrote it (see the FAQ). The tool takes zone names, and there is no reliable way to turn an abbreviation into one.

Rules that changed after your software was built

Offsets for future dates are predictions. An application with an old copy of the time zone database will convert a date after a rule change with the old rule. The UTC instant is right only if the clock reading was right under the rules that actually apply on the day.

Limits & gotchas

• Zone data comes from your browser. The list of zones and every offset are the browser's own copy of the IANA time zone database. Browsers update it with their releases, so a very recent rule change may be missing, and two browsers can disagree. This site does not download any zone data. While testing we saw a Node release with 2024b data and the 2026c data on the build machine disagree about Africa/Casablanca after 2026-09-20.
• Future offsets are predictions. The IANA database records the history and the predicted future of civil time. A government can change the rule at short notice, and then a conversion made earlier for a date after the change is wrong.
• Only zone names, not abbreviations or bare offsets, are accepted as zones. To convert from a fixed offset, use the ISO 8601 validator (it reads -05:00 in a timestamp) or the epoch converter.
• The "skipped time" shift is the gap length, as the tool computes it. Shift later gives the result a JavaScript Date or Java ZonedDateTime gives; shift earlier is the mirror image. Other systems use other conventions (see the snippets), and neither choice is "the" standard answer.
• Range. Dates are limited to the range of a JavaScript Date (about the years -271821 to +275760). Before 1970 many zones used local mean time or had other rules; the database records them only as far as its authors could document, and the page does not warn about that.
• Calendar. Dates are in the proleptic Gregorian calendar, including before the date a country adopted it.
• Leap seconds are not modelled: a reading of 23:59:60 is not accepted here (the ISO 8601 validator explains it).

FAQ

Sources

• IANA: Theory and pragmatics of the tz code and data Used for: The database records the history and the predicted future of civil time scales; names have the form Area/Location (for example Asia/Calcutta was renamed Asia/Kolkata, with the old name kept as a link); the abbreviation list shows that one abbreviation can mean different things (IST appears for India, for Irish time and for Israel).
• IANA: News for the tz database Used for: Recent rule changes made on short notice: release 2026c (2026-07-08) lists Alberta moving to permanent -06 and Morocco to permanent +00 from 2026-09-20; release 2026e (2026-09-29) lists Manitoba moving to permanent -05 on 2026-10-31.
• Python Software Foundation: PEP 495: Local Time Disambiguation Used for: The terms fold (clocks moved back, ambiguous local times) and gap (clocks moved forward, missing local times); the fold attribute; at a gap or fold, fold=0 uses the UTC offset in effect before the transition and fold=1 the offset after it ("the interpretation of the fold attribute is consistent in the fold and gap cases").
• Python Software Foundation: datetime: Basic date and time types Used for: datetime.fold: "Used to disambiguate wall times during a repeated interval"; the values 0 and 1 mean the earlier and later of the two moments.
• Python Software Foundation: zoneinfo: IANA time zone support Used for: ZoneInfo reads the IANA database and honours fold: the offset from before the transition is used when fold=0 and the offset after when fold=1; datetime + timedelta(days=1) is wall-clock arithmetic.
• The Go Authors: Go package time: Date Used for: Time.UnixNano is undefined for dates before the year 1678 or after 2262 (it must fit an int64). time.Date: in a transition that skips or repeats times (the doc's example is the US, 2011), "Date returns a time that is correct in one of the two zones involved in the transition, but it does not guarantee which."
• Oracle: Java SE 21: java.time.ZonedDateTime Used for: For a local date-time that falls in a gap, the zoned date-time is shifted forward by the length of the gap, ending in the later offset; for an overlap the previous offset is retained if there is one, otherwise the earlier offset is used. plusDays works on the local time-line (adding days to the local date-time and converting back), whereas plusHours works on the instant time-line, so adding one hour is always a duration of one hour. Java is not installed on the machine used to build this site, so Java behaviour here is described from the documentation, not executed.
• MDN Web Docs: Date Used for: The supported range (April 20, 271821 BC to September 13, 275760 AD, plus or minus 100,000,000 days); that Date ignores leap seconds; Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991; the date-time string format (a simplification of ISO 8601, 24:00:00 allowed, expanded years of + or - followed by six digits, -000000 disallowed); and that setting a local time inside a DST transition follows the Temporal "compatible" disambiguation: if the local time corresponds to two instants the earlier one is chosen, and if it does not exist the result goes forward by the gap duration (with the New York 2024 example).
• MDN Web Docs: Temporal.ZonedDateTime.from() Used for: The disambiguation option for a local time that is skipped or repeated: "compatible" (default), "earlier", "later" or "reject".
• Ecma International / TC39: ECMAScript Language Specification: Time Values and Time Range; Date.parse; time zone offset helper operations Used for: A time value is milliseconds since 1970-01-01T00:00:00Z with every day exactly 86,400,000 ms (leap seconds are ignored); the range is +-8.64e15 ms (+-100,000,000 days); for a local time that is skipped or repeated, the offset in use before the transition is applied; a skipped local time yields no instant in the time-zone-to-epoch operation.
• MDN Web Docs: Intl.supportedValuesOf() Used for: "timeZone" is a valid key and the call returns a sorted array of unique values supported by the implementation.

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• DST transition finder

  List every clock change of a zone in a year: the exact instant, the offsets, and the local times skipped or repeated.

• Unix epoch converter

  Seconds, milliseconds, microseconds or nanoseconds to a date and back, with the unit guess explained and exact BigInt arithmetic.

• Date difference and add/subtract

  Calendar and elapsed-time arithmetic that is honest about DST, with month-end clamping explained.

• ISO 8601 and RFC 3339 validator

  Check a date-time against both formats and see exactly why a string is or is not valid.