Our Methodology

Clockzilla measures three things and displays them to users: (1) the current true time at your location, (2) the offset between your computer's clock and that true time, and (3) an accuracy estimate of the offset measurement itself. Each value is recomputed every 4 minutes by default, and you can trigger a manual resync at any time.

We use a backend proxy that fetches time from two independent sources and serves the result to your browser:

• Tier 1: TimeAPI.io — a public time service that itself synchronizes with NTP-referenced sources. Used as the primary reference.
• Tier 2: Cloudflare — the HTTP Date: response header from Cloudflare's edge network, which is set from Cloudflare's own NTP-synced infrastructure. Used as a cross-check and fallback.

Both upstream sources are themselves stratum-2 or stratum-3 NTP clients, synchronized against atomic clocks at major reference time facilities (USNO, NIST, and others). The chain from atomic clock → reference server → upstream API → our backend → your browser introduces some latency at each step, but preserves a complete chain of trust back to atomic time.

Our backend caches upstream time responses for 3 seconds. This means that regardless of how many users hit Clockzilla, we make at most one external request to TimeAPI.io and one to Cloudflare every 3 seconds. The cache is time-stamped at the moment of fetch, and your browser uses the cached timestamp plus the elapsed time on our server to compute the current true time. This trades a tiny amount of precision (a few milliseconds at worst) for a massive reduction in upstream API load.

When your browser asks for the current time, here is what happens:

1. Multi-sample collection. Your browser sends up to 9 timing requests across multiple rounds and multiple sources. For each request, we record the precise local timestamp before sending and after receiving.
2. RTT measurement. For each response, we calculate the Round-Trip Time (RTT). The server's true time is estimated at the midpoint of that round-trip:estimated_server_time = response_timestamp − RTT/2
3. Offset calculation. The offset between your local clock and true time is computed as:offset = estimated_server_time − local_time
4. Outlier removal. We compute the Median Absolute Deviation (MAD) of the sample set and discard any sample whose distance from the median exceeds 3 × MAD. This eliminates samples skewed by transient network congestion or paging delays.
5. Weighted averaging. The final offset is the weighted mean of the surviving samples, with weights inversely proportional to RTT. Faster round-trips get higher weight because shorter network paths produce more accurate measurements.

Each sync produces a final offset and a quality estimate. We report quality using four bands: Excellent (offset confidence within 50 ms), Good (within 500 ms), Fair(within 2 seconds), and Poor (over 2 seconds). Most modern devices on a standard internet connection achieve Excellent or Good. Slow networks, congested Wi-Fi, or heavy CPU load on your device can degrade the reading.

We are honest about what we can and cannot measure:

• Network latency dominates. The minimum achievable accuracy is bounded by your network round-trip time. On a fast connection, this is ~10 ms. On a slow or congested connection, it can be much worse.
• JavaScript timing precision is limited. Browsers deliberately limit performance.now() resolution to ~1 ms (and sometimes more, as a privacy mitigation). Sub-millisecond accuracy is therefore not achievable in a browser.
• Leap seconds are not surfaced. Our sources handle leap seconds upstream, but Clockzilla does not display individual leap seconds because the precision required is below our measurement floor.
• We do not use GPS. Browsers do not have direct access to GPS time. If you need nanosecond-level accuracy, you need a hardware GPS receiver, not a website.

Time zone information for all 150,000+ locations comes from the IANA Time Zone Database (also called tzdata), the international standard for timezone data. We use the latest version available in the Node.js and browser Intl APIs, which is updated automatically as new versions are released. Daylight saving time transition dates, historical offset changes, and political boundary updates are all sourced from IANA.

Sunrise and sunset times are computed using the NOAA Solar Calculator algorithm, the same algorithm published by the U.S. National Oceanic and Atmospheric Administration. Inputs are the city's latitude, longitude, and the current date. Output is accurate to within about 1 minute under typical atmospheric conditions. Astronomical refraction is approximated using a standard atmosphere model.

Articles published on the Clockzilla Journal go through the following process:

1. Topic selection. We choose topics based on questions our users actually ask, common confusion points, and emerging changes in timekeeping (e.g., the abolition of leap seconds in 2035).
2. Drafting. Each article is written from primary sources where possible (IANA, NIST, NOAA, government bodies, peer-reviewed papers).
3. Review. Articles are reviewed for accuracy, citation integrity, and clarity before publication.
4. Maintenance. Articles are reviewed at least annually and updated when underlying facts change (DST rule changes, time zone changes, new technical standards). The “Last reviewed” date at the top of each post reflects the most recent review.

If you find an error in our data, methodology, or articles, please email hello@clockzilla.io. We take corrections seriously and will update the relevant page with a dated notice when an error is fixed.

Clockzilla is a free public service supported by light advertising. We are not a commercial atomic clock vendor, a government time agency, or a certified timekeeping authority. We are an honest implementation of publicly documented algorithms and standards, designed to give anyone a fast, clear answer to the question of what time it really is. Where we cannot give a precise answer, we try to be honest about the limits.