# Is Time.is really Atomic Accurate **URL:** \ **Category:** Uncategorized\ **Created:** [February 12, 2025, 8:34am UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769 "2025-02-12T08:34:46Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Timeclean](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@Timeclean](https://community.ntppool.org/u/Timeclean)\ **Post date:** [February 12, 2025, 8:34am UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/1 "2025-02-12T08:34:46Z")
I noticed Time.is reports synchronization accuracy as ±0.037s on their homepage. Since atomic clocks operate at much higher precision, would this still be considered “atomic accurate” in practice? Curious to hear thoughts from others who’ve tested public time services! ---
**Author:** ![alica](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/alica/32/337_2.png) [@alica](https://community.ntppool.org/u/alica)\ **Post date:** [February 12, 2025, 3:29pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/2 "2025-02-12T15:29:29Z")
Even if it is really connected to a ns accurate atomic clock (I suspect this), wider network delay will degrade it’s precision to ms level. So just hype. ---
**Author:** ![Timeclean](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@Timeclean](https://community.ntppool.org/u/Timeclean)\ **Post date:** [February 12, 2025, 4:43pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/3 "2025-02-12T16:43:20Z")
That makes sense, network latency by itself would introduce ms-level variation even if the source is precise. So practically, there’s no way Time.is can claim “atomic accuracy” beyond syncing to an atomic source? I was testing another system that accounts for network delays differently and it consistently achieves sub 10ms accuracy. Have you seen any public time services that actually optimize for real world precision rather that just marketing atomic sources? ---
**Author:** ![Badeand](https://avatars.discourse-cdn.com/v4/letter/b/c2a13f/32.png) [@Badeand](https://community.ntppool.org/u/Badeand)\ **Post date:** [February 12, 2025, 6:10pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/4 "2025-02-12T18:10:50Z")
Part of the problem is the protocol. HTTP(S) was never meant for low latency communication, and trying to measure the latency, it’s just all over the place. I did play a little around with it: [https://stuff.badeand.net/time/](https://stuff.badeand.net/time/) This server is in the pool. Chrony reports +/- 644us accuracy. Obviously, looking at this webpage, you’re seeing nowhere near this level of accuracy. ---
**Author:** ![Timeclean](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@Timeclean](https://community.ntppool.org/u/Timeclean)\ **Post date:** [February 12, 2025, 7:33pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/5 "2025-02-12T19:33:41Z")
That makes a lot of sense. From what I’ve seen, even with a precise source like Chrony - 644µs, the moment you serve it over HTTPS, the accuracy drops dramatically. I was testing a different method, one that optimizes for sub-10ms real-world accuracy despite the protocol limitations. Have you experimented with any ways to compensate for the network delay issue? Or do you think HTTP(S)-based time services will always be limited by this? ---
**Author:** ![Badeand](https://avatars.discourse-cdn.com/v4/letter/b/c2a13f/32.png) [@Badeand](https://community.ntppool.org/u/Badeand)\ **Post date:** [February 12, 2025, 10:10pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/6 "2025-02-12T22:10:48Z")
> [@Timeclean](#): > > Have you experimented with any ways to compensate for the network delay issue? After getting the timestamp from the server, it adds half the round trip time. Don’t know of any other ways of doing it. The way it gets the timestamp from the server is also by requesting /server-time, which serves a binary integer, and has a minimal amount of headers to reduce the transfer time. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [February 13, 2025, 12:55am UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/7 "2025-02-13T00:55:34Z")
PHK wrote some [notes](http://phk.freebsd.dk/time/20151129/) on time over HTTPS. I believe his focus was getting enough time sync for security. There are quite a few network paths with significant asymmetry. 1/2 RTT is a firm limit ---
**Author:** ![Badeand](https://avatars.discourse-cdn.com/v4/letter/b/c2a13f/32.png) [@Badeand](https://community.ntppool.org/u/Badeand)\ **Post date:** [February 13, 2025, 5:19pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/8 "2025-02-13T17:19:42Z")
> [@stevesommars](#): > > PHK wrote some [notes](http://phk.freebsd.dk/time/20151129/) on time over HTTPS. I believe his focus was getting enough time sync for security. Oh, there’s a standard like that? Went ahead and implemented it on my server: ```auto curl -I https://stuff.badeand.net/.well-known/time HTTP/2 204 server: nginx date: Thu, 13 Feb 2025 17:17:17 GMT x-httpstime: 1739467037.480 access-control-allow-origin: * access-control-allow-methods: GET, HEAD ``` Since the specs clearly states you need permission to use a server for the purpose of time synchronisation using this standard, I hereby grant permission to use my web server (specifically on the [stuff.badeand.net](http://stuff.badeand.net) subdomain) for this purpose to the members of this forum. ---
**Author:** ![marco.davids](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/marco.davids/32/767_2.png) [@marco.davids](https://community.ntppool.org/u/marco.davids)\ **Post date:** [February 14, 2025, 6:36pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/9 "2025-02-14T18:36:24Z")
> [@Badeand](#): > > I did play a little around with it: > [https://stuff.badeand.net/time/](https://stuff.badeand.net/time/) Reminds me of [https://uhr.ptb.de/](https://uhr.ptb.de/) (or our Dutch version [https://klok.sidnlabs.nl:8123/](https://klok.sidnlabs.nl:8123/)). I don’t remember if it takes network delays into account though. ---
**Author:** ![marco.davids](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/marco.davids/32/767_2.png) [@marco.davids](https://community.ntppool.org/u/marco.davids)\ **Post date:** [February 14, 2025, 6:44pm UTC](https://community.ntppool.org/t/is-time-is-really-atomic-accurate/3769/10 "2025-02-14T18:44:59Z")
> [@stevesommars](#): > > PHK wrote some [notes](http://phk.freebsd.dk/time/20151129/) on time over HTTPS. Just for the sake of completeness; there is also [https://www.vervest.org/htp/](https://www.vervest.org/htp/)