Paste a column of naive local timestamps and an IANA time zone. Every row that falls in a gap (a wall time that never existed) or a fold (a wall time that happened twice) is listed with its UTC value under the Temporal, Python and PostgreSQL rules, plus what pandas will do with the column. Everything runs in this page; nothing leaves your browser.
1. Input
Accepted: YYYY-MM-DD HH:MM, YYYY-MM-DD HH:MM:SS, the same with a T, an optional .fraction of 1 to 9 digits after the seconds, and a date alone (read as midnight). Slash dates only with the date order chosen below. An empty cell is kept as NaT.
Any identifier your browser accepts. The suggestion list is a convenience only.
Ctrl or Cmd + Enter runs it.
2. Results
Gap and fold rows
Every UTC value is YYYY-MM-DDTHH:MM:SS[.fraction]Z. A DISAGREEMENT badge marks rows where the Python and Temporal default and PostgreSQL write different instants. Python fold=0 is the earlier instant on a fold but the later instant on a gap. The column sources are listed under the table.
Column sources
Temporal 'earlier', 'later', 'compatible', 'reject': the disambiguation option of Temporal.PlainDateTime.prototype.toZonedDateTime, documented at tc39.es/proposal-temporal/docs/zoneddatetime.html. 'compatible' is the default: "Acts like 'earlier' for backward transitions and 'later' for forward transitions."
Python fold=0 and fold=1: PEP 495, section "Mind the Gap": "the rules in effect before the transition should be used if fold=0. Otherwise, the rules in effect after the transition should be used." So fold=0 is the earlier instant on a fold but the later instant on a gap.
PostgreSQL: Appendix B.2, "Handling of Invalid or Ambiguous Timestamps": "an invalid timestamp that appears to fall within a jump-forward daylight savings transition is assigned the UTC offset that prevailed in the time zone just before the transition, while an ambiguous timestamp that could fall on either side of a jump-back transition is assigned the UTC offset that prevailed just after the transition." That is the later instant on both kinds of row.
RFC 9557 column: the suffix syntax of RFC 9557 section 4.1, time-zone = "[" critical-flag time-zone-name "]", written without the critical flag.
Transitions used
This page does not know which tz database release your browser carries; these are the transitions it used.
Rejected and flagged rows
Export
3. Self test
Runs on load. Known answers for gaps, folds, sub-minute offsets, the parser and the pandas predictor, plus one assertion built to fail so a self test that stopped running would be visible. When this browser has Temporal, the page also compares its own classifier with Temporal around every transition from 1970 to 2040 in a spread of zones and prints the counts it computed.
Every assertion
Why the columns disagree
Each system follows a published rule, and the rules differ only on fold rows. For America/New_York 2025-11-02 01:30, Python datetime with zoneinfo (fold=0 by default) gives 2025-11-02T05:30:00Z, Temporal's default 'compatible' gives 2025-11-02T01:30:00-04:00 (also 05:30Z), and PostgreSQL's '2025-11-02 01:30'::timestamp AT TIME ZONE 'America/New_York' gives 2025-11-02 06:30:00+00. For the gap row 2025-03-09 02:30 all three give 07:30Z. pandas raises by default on both kinds of row. The page never calls an offset "DST" or "standard": the tz database encodes Europe/Dublin with a negative save value, so Dublin's summer +01:00 is its standard time in that data.
The pandas predictor reimplements the ambiguous='infer' rule of pandas 3.0.5 tzconversion.pyx (BSD 3-Clause, see the README) and was re-checked against pandas 3.0.6. It uses this browser's transitions; pandas uses the tz database your Python reads. It does not emulate nonexistent='shift_forward', 'shift_backward' or a timedelta. Independent project: not affiliated with or endorsed by the pandas project, the PostgreSQL Global Development Group, the Python Software Foundation, TC39 or IANA.