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.
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.
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.
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.
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.
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...
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).
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.
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.
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!
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
219 comments
[ 3.7 ms ] story [ 254 ms ] threadNIST 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:
---The nice part is that save for the custom web analytics code from digitalgov.gov as well as jquery, it's not minimized.
setInterval(function() {
}, 600000);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.
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.
Sadly, IE 11 isn't going away any time soon.
But to answer your specific question, regardless of whether it's needed or not, it's mandatory. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/me... requirement #2
https://www.usds.gov/
https://18f.gsa.gov/
There’s even an open source project around the public analytics.usa.gov dashboard:
https://github.com/18F/analytics.usa.gov
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.
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.
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.
https://analytics.usa.gov/
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.
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)
Grab a screenshot (https://i.imgur.com/9ynIz5G.jpg) and drop it in here (https://www.color-blindness.com/coblis-color-blindness-simul...)
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 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.
Using 24 hours is "military time" there.
https://i.imgur.com/dFrM24l.jpg
Edit: holy cow that screenshot became dated very quickly. Map was updated to fix Florida and Texas; new screenshot as of 9:35 UTC-5:
https://i.imgur.com/9ynIz5G.jpg
https://time.gov/scripts/zzz__0fd3fed7f945928bf590af174cd541...
It's basically:
with added corrections. Grep for to see all of it.Thank you!
Because of all this, you can travel less than 100 miles in a straight line and have to change your clock six times...
It also showed a world map and where the sun was currently shining.
I only know it used to be one of the first results on googling "current time".
Edit: fixed now. Quick work for a Friday night!
https://en.wikipedia.org/wiki/Time_in_the_United_States
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.
edit: fixed! Nice!
Hello NIST employee watching this thread. Nice quick turnaround!
Really great refresh from the old version of the site.
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.
It looked precisely like this, but was a java applet.
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!
https://i.imgur.com/703v1cC.jpg
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.
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.
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)
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.
> 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.
https://www.nist.gov/pml/time-and-frequency-division/about-t...
Anyone know how true this is? Particularly for mobile/asymmetric bandwidth connections - what might the errors bars be?
and grep for realTimeDif
Well that’s not something you see every day.
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.
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.
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.
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).
SNTP is notoriously less accurate but is usually "good enough".
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 only wish it had more date display options: day number and ISO8601 Week Number.
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.
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.
[1] https://xkcd.com/1172/
https://www.usno.navy.mil/USNO/time/telephone-time