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.
setInterval(function() {
location.reload();
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
There’s even an open source project around the public analytics.usa.gov dashboard:
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.
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.