How we measure server time
What OnTheSecond does
- Measures a website’s server clock to the millisecond against standard time (KRISS and Google, via NTP) and tells you the exact moment to click, allowing for your network delay.
- Keeps measuring until the opening: every minute in the last 30 minutes, checking every server behind the site, and updates the click time if the clock changes.
- Lets anyone check its accuracy: a public test server whose clock we set off by a random amount each day, and a self-check against standard time every 10 minutes (results).
We compare a website’s server clock with standard time, to the millisecond, and keep measuring it again until the opening time you set.
Reading a server’s clock
Every time a website answers a request, the answer carries a Date line with the server’s current time. That time is given only to the whole second, such as 10:00:00. So a single answer tells us that the server’s clock was somewhere inside that second, and no more.
Narrowing it down
It works like a higher-or-lower guessing game. We want to find the exact moment the server’s second ticks over, so we send a request at the moment we expect it. If the answer says :59, the tick hasn’t happened yet: the answer is later. If it says :00, it already has: the answer is earlier. Either way, half of the remaining range is ruled out.
We start from a whole second (1000 ms) and keep halving it: 500 ms, 250 ms and so on. For every request we also note when it left and when the answer came back, so we never narrow past the time one round trip takes. For a nearby server that leaves a few milliseconds.
Network delay
A slow connection does not push the result to one side. It makes the range wider. Even when the route is slower in one direction than the other, the true value stays inside that range. That is why each reading shows three numbers separately: the difference from standard time, its ± margin, and the round trip time (RTT). We drop a reading that has fewer than 6 answers. When a site is busy and the margin comes out wider than ±150 ms, we don’t use that reading as the answer. We use it to check that the last precise reading still holds. If it doesn’t, the clock has changed, and we switch to the new reading and set the click time to its late edge so you don’t arrive early.
Our reference: standard time
Our server keeps its system clock on standard time with chrony, a widely used time-sync program. Every 10 minutes we check it again against public time servers run by KRISS (Korea Research Institute of Standards and Science) and Google, and take the answer with the shortest round trip. One answer from a time server can only say that the true time lies within ± half of its round trip. If our system clock is already inside that range, we use it as it is. We correct it only when it falls outside.
What we checked
On 1 November 2026, from our server in Seoul, we measured sites served by CDNs from different companies: 3 Korean ticket sellers and more than 10 international ticket and shopping sites. Every one of them matched standard time within its own margin.
Because we measure from Seoul, for a site spread across a CDN we read the clock of the server that answers Seoul. The server that answers you in another country may be a different one. In our checks these clocks have been accurate, but a reading for a global site is a strong guide, not a guarantee.