Two entries both say 01:30 on November 1, 2026, in New York. Subtracting the clock labels gives zero. If the first is 01:30 at UTC−04:00 and the second is 01:30 at UTC−05:00, sixty minutes have passed. The missing information is which occurrence of 01:30 each entry means.
We generated seven cases and ran a Python check, then compared every result with the JavaScript module used by the calculator below. These are constructed examples, not recordings from someone's calendar. We did not measure a scheduling benefit or test a calendar provider.
Keep three numbers separate
A clock-label difference compares the written dates and times without their UTC offsets. An offset change compares the end offset with the start offset. Elapsed time is the first number minus the second. Both dates matter; crossing midnight is not a reason to discard the end date.
For the repeated 01:30, the clock difference is 0. The offset change is −300 − (−240) = −60 minutes. The elapsed time is therefore 0 − (−60) = 60. In UTC, the endpoints are 05:30 and 06:30. This is a change of representation, not a second hour added by software.
| Generated case | Written start and end | Clock difference | Elapsed |
|---|---|---|---|
| New York spring | Mar 8, 01:30 −05:00 → 03:30 −04:00 | 120 min | 60 min |
| New York autumn span | Nov 1, 00:30 −04:00 → 02:30 −05:00 | 120 min | 180 min |
| Repeated New York hour | Nov 1, 01:30 −04:00 → 01:30 −05:00 | 0 min | 60 min |
| Seoul midnight | Oct 24, 23:30 +09:00 → Oct 25, 00:30 +09:00 | 60 min | 60 min |
| Seoul and UTC labels | Oct 25, 09:00 +09:00 → Oct 25, 00:00 +00:00 | −540 min | 0 min |
| Ordinary Seoul hour | Oct 25, 09:00 +09:00 → 10:00 +09:00 | 60 min | 60 min |
| Kathmandu and UTC labels | Oct 25, 09:00 +05:45 → 03:30 +00:00 | −330 min | 15 min |
All dates in this table are in 2026. The negative clock-label differences are comparisons of differently labelled clocks; they are not negative elapsed durations. A whole-hour offset assumption would also lose the Kathmandu example's fifteen-minute result.
Change one offset and inspect the UTC endpoints
The following calculator starts with a generated example. Choose another example or edit the four fields. Keep the dates and both offsets visible when sharing a calculation. The result is only an arithmetic comparison of the supplied values. It does not identify a city or decide whether those values describe a valid local time there.
Compare clock labels with elapsed time
Inputs are calculated on this page without saving or transmission. This does not validate a region’s actual daylight-saving rules.
For a useful check, select the repeated-hour case and change the end offset from −05:00 to −04:00. The elapsed result changes from 60 to 0 because both endpoints now describe the same instant. Restore the preset before moving to the next example. No meeting was moved; only the constructed input changed.
Why the Python subtraction needs an explicit question
Our regional inputs use Python's ZoneInfo. Its fold value distinguishes the two occurrences of an ambiguous local time. The zoneinfo documentation explains which side of a transition fold selects. The program requires that choice instead of silently accepting the first occurrence.
An important trap appeared in the generated cases: subtracting two Python datetimes with the same tzinfo object follows their clock labels. The repeated-hour example returns zero by that operation. The datetime subtraction rules document this behavior. It is not a failed Python test. We convert both endpoints to UTC before subtracting when the question is elapsed time, obtaining 60 minutes, and preserve both results in the JSON.
A valid offset is not proof that the local time exists
The regional check also tries New York at 02:30 on March 8, 2026. Converting that candidate to UTC and back does not return the requested local time, so our program rejects it. It separately rejects the repeated autumn time without a fold choice. The browser calculator has no regional timezone database lookup: entering a plausible date and offset can produce arithmetic even when the corresponding local time is invalid in a particular city.
For a real invitation, obtain its date, regional timezone and unambiguous endpoint from the calendar provider or organiser. Do not guess an offset from the country's name. IANA's timezone database changes when authorities change rules. Our run records hashes of the installed zone files; it is not certification that every device has the newest global rules. Future invitations should be rechecked if rules change.
Reproduce the checks without a private calendar
The Python source, generated CSV, complete results and browser module are public. The Python version needs Python 3.9 or later and available system timezone data. If your environment lacks that data, the table and explicit-offset calculator remain usable without installing anything for this article.
Seven valid cases matched the specified totals. The builder additionally ran the actual browser module's seven presets against the Python outputs. Six regional/input cases were deliberately rejected: a nonexistent time, an ambiguous time without its occurrence, an invalid date, an invalid fold, a missing offset and reversed UTC endpoints. These are successful rejection checks, not failed meetings or Google decisions. The same author produced both implementations; cross-checks are not independent expert review.
The model is minute-precision, excludes leap seconds and recurrence expansion, and does not import calendars or optimise a schedule. It answers how long two unambiguous instants are apart. To combine several appointments after resolving their endpoints, continue with the separate overlap and occupancy calculation; adding event lengths still does not remove collisions.