Methodology & Data Sources

This page explains exactly how the numbers on WorldTimeWise are produced: what data we use, what algorithms we use, and where the limits are. We believe a time tool should be able to say how it works.

Time zones: the IANA database, via your browser

Every time zone conversion, offset, and daylight saving answer on this site comes from the IANA time zone database (often called "tzdata"). We do not keep our own copy of time zone rules and we do not hard-code UTC offsets anywhere.

The database reaches our code through the Intl API built into your browser (`Intl.DateTimeFormat` with a `timeZone` option). Your browser ships with a copy of the IANA database, updated when the browser updates. This means:

  • Conversions use the rules actually in force on the date you ask about, not just today's rules. A time in 1995 gets 1995's rules.
  • We never assume a zone's offset is fixed. Zones that have changed offsets historically, or that observe daylight saving, are handled by the database, not by us.

Daylight saving time

DST start and end dates shown on the site are derived from the same IANA data. We compute them by walking the calendar and watching for offset changes, rather than typing in dates by hand — so when a government changes its DST schedule and your browser picks up the new database, our pages reflect it automatically.

Two edge cases deserve a mention:

  • Skipped times. When clocks spring forward (e.g. 2:00 → 3:00 in New York on 8 March 2026), a time like 2:30 does not exist that day. Our converter says so rather than silently picking a nearby hour.
  • Repeated times. When clocks fall back, a time like 1:30 happens twice. We flag the ambiguity instead of guessing.

Sunrise, sunset, and the moon

Sunrise, sunset, solar noon, twilight times, and day length are calculated in your browser with the open-source suncalc library (BSD licence), which implements the standard solar-position algorithm in the *Astronomical Algorithms* tradition (Meeus). Inputs are latitude, longitude, and date; outputs are the sun's rise, set, and twilight instants for that location. Moon phase and illumination use suncalc's lunar model, accurate to well within a day for phase purposes.

Near the poles the sun may not rise or set on a given day. When that happens we say so ("polar day" or "polar night") instead of showing a meaningless time.

Date math

All date arithmetic follows ISO 8601 conventions: the Gregorian calendar, Monday as the first day of the week for ISO week numbers, and unambiguous `YYYY-MM-DD` handling. Leap-year rules are the standard ones (divisible by 4, except centuries not divisible by 400 — so 2000 was a leap year and 2100 will not be). Day counts are computed from calendar dates, not milliseconds, so daylight saving transitions can't shift a result by a day.

What we can't promise

  • Your browser's data may lag. If a country announces a time zone change tomorrow, your browser's IANA copy won't know until it updates.
  • Historical edge cases. Time zones before roughly 1900, and zones with unusual histories (e.g. Samoa skipping 30 December 2011), follow the database; we surface what it says but have not hand-verified every historical record.
  • Seconds-level precision. We don't account for leap seconds; displayed seconds are conventional clock time, not atomic time.
  • Astronomy simplifications. Sunrise/sunset ignore local terrain, buildings, and atmospheric quirks; they assume a flat horizon.

For important uses — travel, legal deadlines, medical or safety scheduling — always cross-check against an authoritative source. See our terms.