Methodology & Accuracy
Every clock and conversion on TimeConvertor.net is powered by a small, tested engine. This page documents where the data comes from, the conventions at the tricky edges, and exactly what "accurate" means here.
The data source: IANA via your browser
Time zone rules — offsets, daylight-saving start and end dates, historical changes — come from
the IANA Time Zone Database, the global authority that operating systems and programming
languages ship. We access it through the browser's built-in Intl API rather than bundling
a copy, which has a decisive advantage: live times can never be staler than your own browser's tz
data, which updates with the browser. (The static standard/DST offset columns on the World Clock and
city pages are computed when the site is built and refresh with each site build.) Nothing here hard-codes
an offset. The
55 cities we list are identified by their IANA zone names (for example
America/New_York), never by ambiguous abbreviations.
Clock accuracy, honestly stated
Live clocks display your device's clock, mapped into each city's zone. Modern devices synchronize via NTP and are typically accurate to well under a second — but we do not measure or correct your device's drift, and we make no atomic-time claim. If your device's clock is wrong, every clock here will be wrong by the same amount. Display updates are aligned to the top of each second.
Conversion conventions at the DST edges
- Offsets are evaluated for the exact instant being converted — never a fixed city-to-city table — so seasonal shifts and mismatched DST calendars come out right.
- Nonexistent times (the spring-forward gap — e.g. 2:30 AM on a night clocks jump from 2:00 to 3:00) are resolved deterministically to a nearby real instant rather than rejected.
- Ambiguous times (the fall-back hour that occurs twice) resolve deterministically to one of the two instants. Which duplicate — and whether a gap resolves forward or backward — can differ between zones; the result is always a real instant.
- DST detection compares an instant's offset with the zone's standard offset, taken as the smaller of its January and July offsets — correct in both hemispheres because DST always moves clocks forward.
- Unix timestamps follow the standard convention: seconds since 1970-01-01 00:00 UTC, ignoring leap seconds; values of 1012 or larger are interpreted as milliseconds.
What these tools do not do
We do not predict future rule changes (jurisdictions occasionally change DST law with short notice — the IANA database follows reality, and your browser follows the database), we do not show historical times before 1900 or beyond 2200, and we do not account for leap seconds. We also deliberately omit cities whose clock changes are not seasonal — Morocco, for example, shifts around Ramadan — because our standard/DST labeling would misrepresent them; conversions for such zones still work correctly if entered by IANA name elsewhere, since offsets are always evaluated per instant. For legally critical timing — contracts, filings, launches — confirm against an official source.
Tested against known cases
The engine's automated tests pin the classic hazards: DST in both hemispheres (New York and Sydney, whose seasons invert), half-hour and 45-minute zones (India, Nepal), conversions that cross the calendar line in both directions, the nonexistent and ambiguous wall times around the 2026 US transitions, and Unix timestamp round-trips. The worked examples in page copy are computed at build time by this same engine, so the copy cannot drift from the code. If you believe a result is wrong, see the contact page — confirmed issues are fixed in the engine and locked in with a new test.