サーバー時間

The header is truncated, not rounded. A server whose real time is 09:30:00.900 still writes 09:30:00 — it drops the fraction rather than rounding to the nearest second.

So a single reading is not merely imprecise, it is biased. The value you get is somewhere between 0 and 1000 milliseconds behind the truth, averaging 500ms, and always in the same direction. Requesting again does not help: the second reading is biased the same way. Averaging a hundred of them converges neatly on an answer that is half a second slow.

This is the failure mode to look for in any server time display. If a page shows a server's clock without saying anything about uncertainty, the most likely explanation is that it parsed the header and printed it.

The way out is to stop asking each response for an answer and ask it for a limit instead. Suppose a request left at local time s and the response arrived at r carrying header value D. The server stamped that header at some instant between s and r. If the server's clock is ahead of yours by θ, truncation to D means the server's true time at that instant was at least D and less than D + 1000.

Rearranged, that single response tells you θ lies somewhere in the range from D − r to D + 1000 − s. It is not an answer; it is a fence. Every response builds another fence, the true offset has to be inside all of them, and so the answer is where they overlap.

Two things fall out of this for free. A sample taken just before a second rolls over and one taken just after produce fences from opposite directions, and their overlap is narrow — the rollover pins the offset down without ever needing to be detected as a special case. And a response that came back fast produces a narrow fence, so it automatically outweighs one delayed by queueing. There is no filtering step and no discarding of outliers, because a slow sample simply constrains less.

This tool takes up to 22 samples about 70ms apart, which spans more than a full second and therefore guarantees that both edges of the truncation window are observed.

Large ticketing sites do not answer from a single server. Requests land on whichever node a load balancer picks, and those nodes do not necessarily agree with each other.

This produces a specific kind of lie. Samples within one measurement often ride the same keep-alive connection and therefore reach the same node, so they agree beautifully — and the tool reports a tight bound describing one machine's precision rather than the spread across the pool. During testing, two Korean ticketing hosts reported confidence of ±33–99ms while independent runs against them disagreed by 400–500ms.

Because round-robin balancers hand consecutive requests to different nodes, splitting the samples by parity and comparing the two halves surfaces exactly that disagreement. Whatever gap appears between them becomes a floor on the uncertainty reported. Overstating precision is the worse error here: someone timing a purchase needs to know how much slack to leave, and a confident wrong number is more dangerous than an honest wide one.

Each sample's fence is only as narrow as its round trip, which means network distance sets a hard ceiling on accuracy that no algorithm can lift.

This is not theoretical. This endpoint was originally executing in Virginia while its visitors arrived through Seoul, so every probe of a Korean host crossed the Pacific twice — roughly 700–790ms round trip against 20–50ms from inside Korea. The reported uncertainty inflated to ±451–625ms, and the fixed time budget ran out after six or seven samples instead of the full 22, so the truncation window was never fully covered either. Moving execution to Seoul mattered more than every refinement above it.

The same logic applies to you. If you are measuring a Korean ticketing site, you want the measurement taken from Korea, and if you are on a satellite link or a VPN routed through another continent, the honest uncertainty will be larger.

A single measurement fires up to 22 requests at the target. That is unremarkable for one visitor and unacceptable when hundreds of people check the same host in the same few seconds — which is precisely when this tool is used.

Measurements are therefore cached for ten seconds per host and concurrent requests for the same host collapse onto one measurement. A clock offset drifts at parts per million, so ten seconds of age costs well under a millisecond, comfortably inside the uncertainty already reported. The freshness given up is negligible; being rate-limited at the moment the tool matters most would not be. Auditing the preset list did in fact hammer one Korean ticketing host until it began refusing, and it recovered once the requests were spaced out.