How Chochim measures server time: estimating milliseconds from a one-second Date header, and its limits
As of November 1, 2026, this describes the measurement code actually running on Chochim's server. If the method changes, we update this article.
Every web response carries a Date header saying what time it is. The catch is that it only goes to the second: the format defined by the HTTP standard (RFC 9110) looks like Sun, 01 Nov 2026 06:00:00 GMT. In ticketing, 0.3 seconds can move you thousands of places in a queue. So how does Chochim estimate milliseconds from one-second information?
The core idea: "right now, their clock is inside this one-second window"
If the Date header says 12:00:00, the remote clock was somewhere at or after 12:00:00.000 and before 12:00:01.000 at that moment. We do not know the exact value, but we know the range.
For each request, Chochim's server records three things:
- s0: Chochim's clock when the request was sent
- s1: Chochim's clock when the response arrived
- D: the response's Date header (to the second)
The remote server stamped Date somewhere between s0 and s1, so "remote clock minus Chochim clock" must lie between D − s1 and D + 1 s − s0. Measure this several times and keep only the overlap, and the range keeps shrinking.
Worked example: narrowing the range in three requests
The numbers below are illustrative. Chochim's 12:00:00.000 is 0 ms, and the difference (remote minus Chochim) is in ms.
| Request | Sent s0 | Received s1 | Date header | Possible difference | Overlap so far |
|---|---|---|---|---|---|
| 1 | 120 | 180 | 12:00:00 | −180 to +880 | −180 to +880 |
| 2 | 830 | 890 | 12:00:01 | +110 to +1170 | +110 to +880 |
| 3 | 1450 | 1510 | 12:00:01 | −510 to +550 | +110 to +550 |
Three requests shrink the range from 1,060 ms to 440 ms. Chochim reports the midpoint (+330 ms) as the measurement and half the range (±220 ms) as the error: "the remote server is about 0.33 s ahead of Chochim." Real measurements repeat this up to ten times, so the range gets much narrower.
What Chochim actually does
- Ten requests to the site: HEAD requests (headers only, no body) to the site's front page, with no-cache to avoid cached responses, without following redirects.
- Deliberately uneven spacing: the gap between requests varies between 97 and 185 ms. With an even gap, every request would hit the same point relative to the second boundary and the range would not shrink well.
- Overlap the ranges: as in the example, take the midpoint and half-width. Fewer than three valid responses counts as a failed measurement.
- When the ranges do not overlap at all: large sites answer from several servers, and if their clocks differ slightly the ranges can contradict each other. Then Chochim uses the median of the per-response estimates and shows a wide ±500 ms error.
- Sharing results for 30 seconds: if many people measure the same site at once, that site gets flooded. So one result is stored and shared for 30 seconds.
Your device versus Chochim's server is measured separately
The steps above give "site clock minus Chochim server clock." To show the right time on your screen, we also need "Chochim server clock minus your device clock." Your browser sends four short requests to Chochim and uses the one with the fastest round trip, assuming the reply was created halfway through the round trip. This is the same idea used by NTP, the internet's time synchronization standard. The round trip is timed with the browser's high-resolution timer (performance.now), and this is redone every minute.
The final number on screen is the sum of the two differences, and the displayed error is "range error + half the round trip."
What this method cannot tell you
- The queue server may be different. Chochim measures the clock behind the site's front page. When the booking button actually opens is decided by separate queue or booking servers and how the site is run.
- It may be a CDN clock. Large sites are often answered by a content delivery network, so the clock may be the CDN's rather than the booking server's. Most CDNs are synchronized to standard time.
- Sites without a Date header cannot be measured; Chochim says the site does not report its server time.
- An unstable connection increases the error. Wired beats Wi-Fi, and quiet hours beat busy ones.
So treat Chochim's number as a reference clock for judging the exact moment. For what a server clock is, see What is server time?; for clicking on the minute, the ticketing guide; and for human limits, the reaction time guide.