There are two independent timekeeping authorities in the US, the NIST and the Navy, which maintain the official civil and military time respectively. By policy the civil and military time are synchronized, and the precise offset between civil and military time is monitored by the NIST as a form of quality assurance. The offset between the two is generally less than the error in the comparison method.
The Navy offers a similar online time service although it is clearly far less developed from a design perspective (https://www.usno.navy.mil/USNO/time/display-clocks/simpletim...). However, what's perhaps more useful is that the Navy continues to offer a telephone time service (202-762-1401) while NIST does not. Additionally, the GPS time, while operated by the Air Force, is precisely synchronized to the Navy time plus or minus a known offset (due to the decision to no longer apply leap seconds to the GPS constellation to avoid leap-second-related problems).
There is some history here. The NIST is interested in timekeeping from a metrological perspective since it is important to many commercial and scientific pursuits. The Navy, on the other hand, has long been interested in accurate timekeeping because it is required for celestial navigation. The transit telescope maintained at the Naval Observatory comes from the legacy of the Naval Observatory as a tool to correctly adjust the clocks used by ships at sea for navigation. Similarly, many of the most significant advances in mechanical timekeeping were spurred by the need for compact and reliable clocks for use at sea.
The Navy operates master clock equipment at Schriever AFB for closer proximity to the NIST equipment at Boulder, but the primary means of comparison of the two time bases is by observing the GPS time. Because of the simplicity and low cost of GPS time sources, GPS is as ubiquitous for time measurement as it is for navigation.
One interesting thing about Schriever AFB and its critical role in the GPS system... It's one of the few US military facilities in the 48 states that has a true double perimeter fence system around it. Take a look at it from google earth in satellite/aerial view. The security around it is very nearly as high as the Pantex plant in Texas (nuclear bomb assembly/disassembly facility).
Having grown up in the USSR (not that this fact necessarily gives me any special points in this discussion), I simply look at it like this: a lot more nationalities contributed to accomplishments and failures of the USSR than Russians. For example, it's not just the Russians that helped defeat Germany in WWII, and it's not just the Russians that made Chernobyl (in Ukraine, BTW) the disaster that it became.
The difference is that the USSR covered a much wider geographical net than it's successor states. Giving Russia credit as if it were the USSR is like giving sole credit for a team's work to the loudest programmer in the group.
Thank you very much; this is a very detailed post that covers several things I was wholly unaware of. One minor gripe:
> However, what's perhaps more useful is that the Navy continues to offer a telephone time service (202-762-1401) while NIST does not.
NIST also has a phone # service, but regardless, I'm struggling to think of a scenario where dialing a phone # would be more useful and/or accurate than any other method. I haven't called a number to set my clock since the '90s.
NIST also provides "Automated Computer Time Service" [1] where you can call by modem to get an ASCII time code. It supports baud rates between 9600 and 300.
Can't edit the above comment now, but I just noticed the link got misinterpreted by an Arc bug - I'd rapidly copy-pasted "https...til_nist_has_run_a/?", the link had a questionmark on the end. So I'm not asking a question :)
Yeah, for some reason I thought the NIST had ended that service but evidently it hasn't. That's a bit amusing since there is discussion of ending the shortwave radio service which is significantly more important than the telephone service, although admittedly much more costly to maintain.
Fortunately, so far, WWV/WWVH/WWVB have survived the budget process despite a pseudo-decision having been made to end the service. We'll see how long that continues.
In the 80s it was also very common for local banks to provide a number that would provide time. It was also common for the sign outside the bank to have a clock attached as well. "At the tone the time will be..."
If the history of timekeeping for navigation sounds interesting, check out the book (and movie) “Longitude” by Dava Sobel. It’s an incredible and largely-forgotten story.
So if we're using the Nautical Almanac for navigation purposes,does it matter if we use NIST or Navy? Or is the synchronization very close? Also, where can I learn more? In the sailing community these questions come up, believe it or not.
The phone number doesn't work. Just tried calling it on my cell phone. I'm just getting a constant ringing with nothing picking up I'm very disappointed.
I am curious, when did the decision to make GPS not follow leap seconds occur? had you asked me before I read your comment, I would have said that it doesn't honor leap seconds and never has.
Yeah, so GPS was designed to not apply leap seconds from the start, which is important because there's a field built into the protocol to send the current offset. The reason I describe it as "no longer applying" is because the GPS time is monotonic from UTC at an arbitrary starting point, so it doesn't match up with any of the strictly monotonic time bases either - that is, GPS time is monotonic but does not match the agreed upon international monotonic time standard, TAI, because GPS time has some of the UTC leap seconds applied.
TAI is also, of course, fundamentally just a divergence from UTC caused by not applying leap seconds. However, formally, UTC is defined as TAI plus or minus the leap second offset in order to minimize divergence from UT1 (which is a smoothed astronomical time base rather than monotonic). GPS time is TAI plus or minus a different offset caused by some of the leap seconds being considered.
There is a basis for this, LORAN did the exact same thing but with an earlier divergence point.
Ah, this makes sense. I deal with some data analysis that has times referenced to the GPS epoch, but also includes all the leap seconds added from the GPS epoch through September 19, 2013. So I've spent a fair amount of time dealing with this but haven't had to get as deep as you have. thanks for the detailed reply
Atomic clock timing services that existed before GPS didn't use leap seconds either. GPS time is related to TAI time, which is based on absolute elapsed time so it slowly drifts away from UTC when leap seconds get added. IIRC, GPS time is just TAI/TT time with a different epoch.
I can't comment on accessibility or responsiveness or what have you, but this is a wonderful display. Strong, clear delineations without being too bright or garish, and densely packs a bunch of information together without losing clarity or concision. Love it.
It's brilliant. And the front-end code, though not at all complicated, is clean and easy to understand. I can't speak for code quality, though.
NIST published an update to their About page for time.gov mid-week (https://www.nist.gov/pml/time-and-frequency-division/about-t... ); the only reason I know it was updated today or might've been late last night is because I used the old time.gov to set a watch the day before, and when I opened the tab today, the clock read:
aN:aN:aN
---
The nice part is that save for the custom web analytics code from digitalgov.gov as well as jquery, it's not minimized.
Agreed, really brilliant. The way the different states are colored according to their time zone and then that color reaching out to the labels on top with those ray-like things is actually pretty clever.
Interesting to wonder how often are people needing to come up for a design for this type of information? Am I wrong to think not very often? My point is it's cool to see a design for something that isn't "solved" or that not many have ever really worked on.
> The way the different states are colored according to their time zone and then that color reaching out to the labels on top with those ray-like things is actually pretty clever.
So the different components of this visualization genuinely solve a few different problems around color-blindness (necessary for 508 compliance is my guess, but I'm not an expert here)
The only mode where any two zones next to each other are nearly identical is Red-blind/Protanopia (CMK identical, Y 8% higher in UTC-7 compared to UTC-8†). Monochromacy/Achromatopsia is a close second... and that's where the gradients to the clocks come in - even for those users, there's still a mechanism to distinguish those two zones.
I'd guess some serious usability research went into this.
---
† RGB, though more accurate since we're talking about a screen, would've been a little more complicated to compare in writing since only yellow changed between the two in CMYK
> I'd guess some serious usability research went into this.
I find that unlikely. If they just swapped the blue color of Alaska with the Mountain time zone there would be no ambiguity between adjacent colors at all for any type of color blindness.
They're probably still tinkering with this and that, and the forced reload ensures that what's on the screen isn't too different from what they're actually serving even if users keep their tabs open all day long. If they change something, like moving a timezone boundary, they only need to wait 10 minutes before all clients are updated.
Moreover, any clock that updates itself in JS is also limited by the accuracy of the device's own clock. Periodic reloading ensures that the displayed time doesn't drift far from the server's clock. Of course they could do this by AJAX, but location.reload() also works fine if there's no client state worth preserving.
Yeah, should definitely be done with a XHR/Fetch call. Honestly, I would love if it updated through a websocket considering it's lower latency and can update far more often without the need for expensive HTTPS calls or a reliance on internal clocks.
I don't think their 10 minute update interval is based on the performance limitations of the HTTP protocol, but used because it's simply not necessary to do it more often.
Maintaining an open full duplex connection for a single fetch request every ten minutes sounds like terrible overengineering that in the end is probably much worse performance wise.
Both protocols use TCP as an underlying protocol. So the latency of the timedata from the final request should be pretty much the same (neglectible differences due to larger HTTP header that needs to be sent and parsed on receive). We don't really care about the additional round-trips before, because they don't affect the clockdrift.
However, if you really do care about the clockdrift due to client-server latency there are protocols like NTP that try to calculate that drift and minimize it.
Somewhere in the FAQ they indicate that NIST and the US Navy sync their clocks every 10 minutes. I'd wager that is why they refresh the webpage at that same frequency.
Think a little deeper about that: the government doesn’t need to sell things but that doesn’t mean that the people building sites don’t care about knowing who’s visiting, what they do, or how the site performed. For example, when do you stop spending more money supporting old browsers?
There’s even an open source project around the public analytics.usa.gov dashboard:
Why is it not okay when the NSA does it, but okay when the individual sub-organizations engage in domestic spying like this?
There is nothing special about visitors to .gov websites vs any other major website. You stop supporting old browsers when their installed base gets small enough; this has nothing to do with analytics or those specific sites under surveillance.
If you think this is what the NSA was doing, you should learn more about that. While you’re doing so, ask whether there’s a difference between the owner of a site getting basic visitor information or a third-party compromising other services to get far more personal information which they would otherwise not have access to. This is the difference between me noticing what type of car you drive when you visit and constantly recording every cars’ occupants, destination, and topics of conversation in the entire city.
Finally, you’re also wrong about how sites use analytics: global stats don’t matter much compared to your actual visitors, whose demographics can vary significantly. Every site I’ve worked on since the mid-90s has found that to be important enough to do basic analytics of the sit under discussion here.
This is silent, nonconsensual surveillance of large groups of people. Basically the same thing the NSA does, just in this case scoped to a specific website.
Calling it analytics doesn’t make it not mass surveillance.
It’s not okay when either group does it. I’m surprised to see that “the government should not spy on its citizens” is such a controversial belief.
It looks like it was designed to fit perfectly above the fold on the screen, but then some manager (to put it mildly) came along and made them insert a useless grey bar at the top, pushing everything else down. Nothing a little "Block element..." can't fix, though.
I remember using time.gov about 17 years ago. It was "worse" back then: the home page had two buttons: one that displayed a static time in HTML, the other that displayed a Flash or Java element where the seconds ticked. (Worse compared to today, back then it was good for the time and I appreciated the resource.)
Great job to those of you working on this website! The update looks amazing, and I'm sure I will continue using it for years to come!
In all seriousness I always thought it was a sort of minimal representation of the American flag. The star isn't oriented the way it is on the Texas flag.
That's an amazing improvement, but I'm already nostalgic for the old design. Next you're going to tell me they've upgraded the Space Jam website.
Tangentially, I find myself using https://time.is/ a lot, check it out if you frequently need to check time in another city or verify your clock is synced.
I used to use time.is, but recently it's gotten more and more ads. Now, this new version of time.gov has the feature that compares device time to correct time, so I think I'm going to switch over.
NTP and even SNTP are performance intensive on the server side and so are generally configured to run at a low interval (either a fixed interval or, on Linux, an interval that becomes longer as local clock skew becomes known). This means that, at any random point, there's probably some reasonable amount of local clock skew that has accumulated since the last synchronization despite attempts to compensate by estimating the skew (essentially local skew is not constant, so estimating and offsetting only helps so much).
There is a tradeoff between highly accurate timekeeping vs. the cost of providing the service, and since the vast majority of users will never notice an inaccuracy of even a few seconds, OS vendors default in the direction of lower cost to maintain their NTP infrastructure.
There can be a bit of a tragedy of the commons situation since equipment which relies on the volunteer-operated pool.ntp.org is also somewhat more likely to have their NTP clients configured in an aggressive way that drives up load on that public resource - since the people configuring the client aren't responsible for operating the infrastructure.
Scuse me, I ran an NTP server on a net4501, which has a CPU so slow you can't even imagine it these days, and that left practically all of that CPU free for other work.
NTP is demanding of the CPU and OS, but what it demands isn't a lot of seconds (or a lot of memory), it is being run at precisely the right time. The OS can't run the NTP server when there's nothing else to do, the NTP server needs the right nanoseconds in order to work well.
These being open internet time services though, and especially in the case of time.windows.com, we are talking about millions of clients. You can build a cluster to handle this, as Microsoft has, but it costs money. The issue is especially clear since, at least historically (I'm not sure about now), the popular time.nist.gov was not a cluster but a single machine. It was nearly impossible to carry out a successful NTP session with that machine due to its load, an especially large problem because some well-meaning vendors configured time.nist.gov as a default on embedded devices. The NIST requests that it not be used except as a source for stratum-2 NTP servers but few people would do that today considering the reliability problems.
Eh, my Linux server is off by 2s, and that’s supposed to be server grade hardware.
The reality might simply be that being off by a second doesn’t matter so much, as long as it’s gradual.
For example, Google chose to “smear” a leap second by prolonging each second by a tiny bit, and everything was fine.
And finally, to pay devils advocate, clients being off by +- a few seconds might actually be a good thing. If everyone was aligned to the millisecond 99.99% of the time, then a lot of timing bugs and inconsistencies won’t be surfaced except on the field.
If you're running some form of ntp, the underlying hardware doesn't matter that much. An offset greater than 0.5s is probably caused by ntp not running, time jumps during hibernation, automatic VM live migrations, or other virtualization issues. Not sure how bad a time jump of 0.5s really is, but in the past those did not happen on servers, so there are old ntp configs that attempt to correct it over days. Probably a mistake, because the instant correction of a large time jump should have no worse effects than the time jump itself.
I once forgot to install NTP on a Debian server (It is not installed by default). The skew reached 31s after 2 years and it invalidated all my JWT tokens.
I have a phone connected to a wifu network time.gov states im off by .028. I have gps turned on so suerly I must have better time than anything available over ip, no?
Anyone know how time.gov thinks it knows the time on my device taking into accout ip latency?
Maybe a silly question, but how can they reliably detect and display the error between my system time and the actual time? I would think there'd be some latency introduced while the page is being loaded/drawn, and by the JavaScript code that's displaying/changing the time, among others.
Simple. Measure the latency, and then correct for it!
> When a user connects to www.time.gov on a computer or mobile device, the Javascript in the client's browser checks the local clock on the device and then requests the time from a NIST server, which has been synchronized with UTC(NIST). When the packets containing the NIST time stamp arrive at the client's browser, the device clock is checked again and compared to the first check of the local clock. The result is a measurement the round-trip delay of requesting/receiving the time stamp.
Oh man. I went on a Southwest roadtrip with my wife.
We had an appointment to tour Canyon de Chelly with a Navajo guide on Sunday AM. We checked into a motel just barely on the reservation on Saturday night before the DST change.
When we entered Arizona, it was, I think, on different time from California. But that night, California was going to move onto the same time as Arizona. The Navajo reservation, too, would be changing times, to match Central, I think. My new-to-me car, with a "DST" box checked on the Nav system, and with the theoretical capability to change timezones based on location and DST rules, would do god-knows-what. We of course had to assume our appointment would be on Navajo time, but had no way of knowing whether our cell phones would switch or not, because there was no way of knowing whether there was GPS-based timezone logic, how precise it was, whether timekeeping was only based on the tower you're connected to, and whether the towers in question were on the reservation or outside of it.
Needless to say, we actually set the bedside alarm clock and used it. (of course, these things often go awry as you find out you set it on radio instead of buzzer, and the radio is not tuned to a legitimate station, or the volume is too low, or whatever).
Oh and I later found out the checkbox on my car just literally meant "are you on DST or not". Yeah, even though it has the capability to pull time from the satellites and cell towers, and even though it knows where I am, and in fact WOULD set the clock from GPS, you had to manually set the timezone and current setting of DST as you moved on and off DST.
Was the bedside clock set correctly or was intelligent enough for you to make it on time for the tour? It’s not clear to me from your story what happened with the tour.
It was an old school alarm clock, so you could expect it to at least be consistent, which is all that mattered. I don't remember if we set it ahead, or left it where it was, but we knew where it would be tour time. Whereas we could not trust our phones to not do something funky. Or to do something funky and undesired.
You forgot to say if you made the tour on time! What a cliff hanger! Thankfully I saw the answer in another comment, glad you made it. :o)
I went on a road trip last summer, and as a foreigner was thoroughly confused when driving across Alabama to Georgia, and the time changed. Then I got even more confused as I was driving in Tennessee and Kentucky, and the time just kept changing.
I think I understand time zones in theory, but in practice I always mess up and get it wrong, and confusion and hilarity often ensues. :o)
You just triggered a deeply repressed memory. I had to write some software that integrated a properly designed logistics database with an improperly designed USPS mail piece tracking feed. What constitutes a proper design? UTC timestamps. USPS, at the time, provided a service that allowed mailers to track their individually serialized mail pieces with an impressive level of granularity. Every sort machine reported its model number and the nature of the event, which is very useful when trying to track the cause of damage - as some models were more aggressive than others (speed, bend radius, etc). Unfortunately they only reported times in the local representation... "No problem" a much younger and happier me said, "they have helpfully included the zipcode that the scan occurred in!"
That was an absolute nightmare. Nonsensical timezone pockets, not necessarily along postal lines, arbitrarily changing at what point they switch to daylight saving time... and yes, areas around reservations were the most common offenders. Oh and you can't just cleanly ingest the data - converting it to UTC on import, because you only find out that they switched after you start seeing time travelling mail pieces in your staging datastore. I don't think I'd ever been more tortured by a problem, only a couple of years before that I had been fighting house to house in Fallujah - and that USPS system integration had me wonder if I'd made a mistake in not renewing my contract.
Fucking Indiana was probably the source of 90% of your pain. Time zones and DST were a country free for all there until the mid 2000s IIRC. State couldn’t decide if it wanted to be central time or eastern so everyone got to decide on their own.
Oh I blamed everyone, from USPS and the county level politicians - to the astrologists screwing around with the tz database... Also, and I hope this doesn't offend any surviving perl monks, having only perl at my disposal made it that much more unpleasant. I never touched perl after that project wound down, but I do wonder to what degree that experience influenced my subsequent shift to porting AIX software...
Indiana was certainly involved. I'm sure I've got a copy of a backup of a copy that would contain those old scripts, but I'm no joke starting to get a little upset just thinking about how much time was needlessly wasted on such a stupid problem.
Indiana had some differences like this before April 2006, with most counties following DST and some not following it. Now it’s just most counties using Eastern Time and some using Central Time, with all of them following DST changes.
While I used to use this years ago managing servers I recently pulled up the old version again helping some admins in my org debug why the 2factor Authenticator apps weren’t working for signon.
Both server and client must have synced time.
I validated my phone and desktop’s time using time.gov when the admins claimed that their server was right and my clients were off.
I thought it was kind of funny they would claim their time was accurate without checking it. Also funny that their server and local ntp would be off.
But time.gov saved the day by providing an always available, easy to use standard.
I can't believe all the seconds on that page aren't synchronized. Or at least on my tablet they aren't! They're flipping at slightly different moments. Should have had one timer event firing to change every element at the same tick.
They are all updated in the same JavaScript function.
However each clock is updated in a seperate call to .innerHTML. This means the DOM is updated seperately for each clock instead of just once for all the clocks.
So depending on how eager your browser is about doing layouts, I could imagine different clocks updating on different frames to be a possibility.
I’m fairly sure the JS standard guarantees that no layouting (or any form of rendering) would happen mid function execution. Haven’t looked in the source code yet, but if they do
function updateAllClocks() {
A.innerHTML = ...;
B.innerHTML = ...;
}
Then A and B would update on the screen on the same frame and the order doesn’t matter (If A is not parent of B or vice versa of course)
This is not true if they do a lot of setTimeouts(), but is true for all other “normal” synchronous code.
I thought that was happening at first on my fast desktop, but it seemed to be to be an optical illusion the more I looked at it. I’d probably have to set some breakpoints or something to verify, but it’s Friday night...
How does this work if your time is really far off? The actual time is served over HTTPS (and the server doesn't even listen on port 80), so if your system time is so far off that it's beyond the validity range of the certificate, your browser won't let the site load. Then you won't be able to determine the time, and fix your computer.
This feels like the one website ever that needs to be served over HTTP ;)
First, you shouldn't set the time manually. There's sntp/NTP and whatever windows protocol is.
Second, you should never leave the certificate replacement till the last moment. Even the 3-months certs should be rotated a month before expiry for safety. If your clock is a month off, that's not something the website can help with.
If you’re connecting over http(s) to set the time of a system, you’re doing it wrong. That’s what the NTP servers are for (which don’t require encryption) - https://tf.nist.gov/tf-cgi/servers.cgi
Well it's loading now. It gave a black screen so makes me wonder if maybe it could have been DNS related? Doesn't Safari use system's DNS while Chrome and Firefox is moving to DNS over HTTPS? That could be a very good explanation why, otherwise kinda puzzled about that.
In fact, considering it's from NIST, there's a stunning lack of precision in the map. The controversial Florida timezone split (2000 elections) isn't reflected here either, and the map itself is largely rounded without considering individual locales.
Giant box telling me “ Browser compatibility
To ensure the proper operation of the web clock application, please use the most recent version of Internet Explorer, Firefox, Chrome or Safari, with JavaScript enabled.”
Viewing using latest version of mobile safari, JavaScript enabled.
Not sure if they aren’t detecting browser, aren’t detecting JavaScript, or are just letting everyone know this even if they have the right browser.
I suppose I should be lucky that it’s not twice the size and in French as well.
I have used that very version recently from Mobile Safari. Didn’t realize they had mimicked a Java applet, but I remember thinking that it sure looked like one (knowing it couldn’t be because I was on Mobile Safari).
For a while, Time.gov was one of the poster children for Lazlo (https://en.wikipedia.org/wiki/OpenLaszlo), one of the more interesting cross platform toolsets back in the day (akin to Haxe nowadays). You can see the LZW (lzx) files in older versions of the site in Archive.org Wayback (2007 or so onward). The team translated their purely Java portion into Lazlo then cross compiled into swf for Flash. So, it went from CGI (perl) to Java to Flash to HTML (still via Laszlo) to a few revisions here and there to work around browser changes to finally this latest revamp. See some background in https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=50644 from 2007.
I looked into it and it turns out that on Firefox Developer Edition (v73.0b12 64-bit) returns an incorrect value for Date.getTimezoneOffset() (0 instead of the expected -60). I'm not sure if it's a bug or an anti-tracking/privacy "feature".
It's probably because you have Firefox Developer Edition. Do private windows always open at the same, 4:3 window size? If so, that sounds like the resistFingerprinting about:config entry.
Many years ago I created a site that similarly syncs time between server and clients for the purpose of sharing stopwatches & timers. I found that using a websocket connection yielded a higher precision.
Under UTC time in lower right corner it says 'your device is off by 0.403 seconds'. This is on my android cell phone and is surprising.. wonder where the offset is coming from.
Get a dedicated NTP client app to be certain of your UTC offset. While NIST won’t have messed up their NTP implementation, I don’t trust web browsers to handle time-sensitive things.
I emailed about this but since it seems there may be a NIST employee reading: the "your device clock" does not respect the 24 hour clock display option.
Personally (on desktop) this design strains my eyes. I want to look in the center where there's nothing to grasp, and there's the official statement, black banner, time boxes, time zone titles in highly varying colors/fonts competing with each other. Also I notice the page auto-refreshing in the background.
If you stare at one of the second digits in the center, say the Mountain Time seconds digit, its interesting to note whether you're peripheral vision does or does not detect the other digits changing. For me, it seems number dependent: I see 1-2-3, and 7-8 but the other transitions appear static!
My windows 10 clock was 2.5 seconds slow! And even after forcing a 'sync now' in the OS time settings and refreshing the webpage a few seconds later, it stayed unchanged. I happened to close and re-open the tab and it showed up correctly (within a few 10 ms) about 10 seconds after the sync.
I can accept that maybe they only sync the time once per day, but what the heck could take so long to have the newly synced time percolate up into the browser? I have a 4 core cpu, 32 gig of ram and a couple-year old ssd, with nothing of consequence running at the time.
NTP performance on the public internet is usually limited by the resources of the server, not the client. Maintaining a large number of NTP sessions is surprisingly performance intensive, which is why many stratum 1 internet NTP servers, time.nist.gov for example, are famously unresponsive. This is also why NTP clients usually take a rather conservative approach by e.g. synchronizing at low intervals during normal operation.
Microsoft operates a generously sized pool of NTP servers to reduce this problem, but since the public Windows time service is not intended to maintain particularly high accuracy it is probably still somewhat limited by server resources. You will see similar issues with the 'open' pool.ntp.org service although lower-stratum pool.ntp.org servers usually seem to have comparatively low load.
Additionally, Windows uses a slight 'variant' of NTP which is intentionally lower precision in public-internet scenarios, likely to reduce the load on the Microsoft NTP service and avoid the issues that some public NTP services have had with e.g. routers using conventional Linux NTP clients absolutely hammering them. The Microsoft docs on this don't give a whole lot detail behind the reasoning and technical details though. Windows NTP achieves much higher accuracy when configured to use a local NTP server.
All of this said, 2.5 seconds is still surprising to me. You might be experiencing rather high local clock drift, although that seems less common since OS timekeeping now relies on the various CPU time counters (which are appreciably more accurate than the BIOS real-time clock), although all bets are off in a VM.
The reason it took some time for the difference to apply to the browser is quite simply the method which the time service actually uses to change the system time. Windows behavior is more or less identical to the Linux nptd/chrony behavior in this case, although the configuration parameters are a little different. When the difference between current system time and NTP time is 'reasonably small', the system synchronizes by 'slewing' the system time by redefining a second to be somewhat shorter or longer for a while. This means that it takes a bit for the clocks to converge, but has the upside of not violating the assumptions that software tends to make about the system clock (e.g. that every second will occur exactly once). On Windows and generally on Linux depending on configuration, very large offsets will result in a 'step' where the system time is just abruptly changed, but this can cause some software to misbehave so is avoided (e.g. cron can act up when a whole minute just never occurs due to a step skipping over it).
Thank you for that detail about how the OS handles the update! It makes sense. It reminds me of the tremendous hoops MS goes through to remain backwards compatible at pretty much all costs.
Phones need to work with the cellular network, so they sync their time with the cellular tower using a GSM protocol (NITZ) and not NTP.
Your phone's settings should have a way to sync with the cellular network (for example, if you set a manual time and then choose set time automatically).
Cell towers (edit: in the USA) are usually within a second of time.gov, so your offset should hopefully be under a second after you sync with the cellular network.
While cellular towers uniformly use a GPS time source for TDMA reasons (which is exactly synchronized to the Naval time minus a known offset), they are surprisingly inconsistent about how time information is delivered to handsets. CDMA requires that towers rebroadcast exactly the GPS time, but GSM generally does not. As a result, GSM handsets may have less accurate time sync depending on how the time service is actually provided.
It's somewhat common for CDMA cellular equipment to be used as a stratum-1 time source in lieu of GPS, since CDMA is easier to receive inside buildings. But GSM is unsuitable for this purpose, and since the long-term prognosis for CDMA seems perhaps less than optimistic, some operators may be forced to run a GPA antenna to the roof.
The windows NTP client is notoriously terrible. It causes issues for the amateur radio mode FT8, for example. The authors suggest installing Meinburg NTP instead.
I wish they would upgrade the systems that serve the story. I’ve timed out (given up on it after 30 seconds) trying to read it on over 10 different occasions at different hours of day and night.
Weird that the Gulf and the East Coast get all their little peninsulas and islands, but there's just a squiggle on the California coast where San Francisco should be.
The map actually simplifies the situation significantly. There are two Hopi enclaves within the Navajo Nation, the larger of which has a Navajo enclave nested within it.
Because of all this, you can travel less than 100 miles in a straight line and have to change your clock six times...
Not really, I don't do this anymore. But at a past job I dealt with malware infected computers. One of the first things I'd do out of habit was make sure it had the correct time. We could connect them to a network but it was heavily firewalled which included blocking NTP. Not wanting to have to set time manually all the time I wrote a Powershell script that parsed www.time.gov. I'm sure that script won't work now.
The old site would give you a confidence interval of the time, but the new one doesn't seem to have that. I can't see any estimate of how accurate the time is.
I don't care about the time my computer is set to. I care about the confidence interval between the time displayed on the webpage and ground truth.
The webpage currently says my computer is over 1 second off from the truth. In the old site, it wouldn't tell me anything about my computer. It would tell me a confidence interval between the website's time and the truth, and it was usually about .1 seconds IIRC.
.jpg){kind=link}
The Navy offers a similar online time service although it is clearly far less developed from a design perspective (https://www.usno.navy.mil/USNO/time/display-clocks/simpletim...). However, what's perhaps more useful is that the Navy continues to offer a telephone time service (202-762-1401) while NIST does not. Additionally, the GPS time, while operated by the Air Force, is precisely synchronized to the Navy time plus or minus a known offset (due to the decision to no longer apply leap seconds to the GPS constellation to avoid leap-second-related problems).
There is some history here. The NIST is interested in timekeeping from a metrological perspective since it is important to many commercial and scientific pursuits. The Navy, on the other hand, has long been interested in accurate timekeeping because it is required for celestial navigation. The transit telescope maintained at the Naval Observatory comes from the legacy of the Naval Observatory as a tool to correctly adjust the clocks used by ships at sea for navigation. Similarly, many of the most significant advances in mechanical timekeeping were spurred by the need for compact and reliable clocks for use at sea.
The Navy operates master clock equipment at Schriever AFB for closer proximity to the NIST equipment at Boulder, but the primary means of comparison of the two time bases is by observing the GPS time. Because of the simplicity and low cost of GPS time sources, GPS is as ubiquitous for time measurement as it is for navigation.