Time.gov was upgraded today | Hacker News Reader

Time.gov was upgraded today

time.gov

692 pointsbryant210 comments

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.

I like the Navy version far more.

I tried calling the number but it just kept ringing.

Thus indicating the time: time for lunch.

> However, what's perhaps more useful is that the Navy continues to offer a telephone time service (202-762-1401) while NIST does not.

https://www.nist.gov/pml/time-and-frequency-division/radio-s...

(303) 499-7111 - WWV (Colorado)

(808) 335-4363 - WWVH (Hawaii)

For those who don't know, the callsigns are because the audio used by the phone service is primarily used for broadcast on shortwave / HF radio.

If you're in the US and have a shortwave receiver you can usually pick up the time broadcasts on one of their frequencies any time of day.

https://www.nist.gov/pml/time-and-frequency-division/radio-s...

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).

> Take a look at it from google earth ...

"Sputnik Street"?

The launch of Sputnik 1 by the USSR was the single most important driver of U.S. developing its own space activities. Makes sense to commemorate that.

Thank you for not saying "by the Russians". It's a pet peeve of mine when Russia is used as a proxy for the USSR while the USSR was still intact.

Why? The USSR was, practically speaking, a Russian empire.

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.

If Russia != USSR, then Germany != nazis/the axis

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.

The Axis included Japan and Italy. Without Japan, the US wasn't likely to fight in the war and lead to the outcome we got (or atleast at that speed).

> Why? The USSR was, practically speaking, a Russian empire.

Stalin, one of the most well-known leaders of the USSR, wasn't even Russia: he was born in what is now Georgia.

"The Soviets are our adversary. Our enemy is the Navy".

Looks like it even has a 3rd fence well outside the double fence. And a 4th fence you have to drive through on the road.

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.

In the 2000s, we set clock from cable TV news channels that displayed time on-screen.

In the 80s we called POPCORN (767-2676) to get the current time.

https://www.theatlantic.com/technology/archive/2016/06/remem...

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..."

A somewhat surprising number of these services still exist, mostly just because it's very inexpensive to offer them now.

I remember doing this a lot as a kid! and was sad to see so many of them going away.

https://www.latimes.com/archives/la-xpm-2007-aug-29-fi-lazar...

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.

And the best part? It gets 2,000 calls a day.

[1] https://www.nist.gov/pml/time-and-frequency-division/service...

> It gets 2,000 calls a day.

I would absolutely love to hear from these folks as to what these systems are.

This thread is a tad old now so this link is primarily for posterity, but I couldn't not share this elsewhere: https://www.reddit.com/r/retrocomputing/comments/f2i9s4/have...?

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.

NIST also operates WWV which broadcasts the time.

https://en.wikipedia.org/wiki/WWV_(radio_station)

https://www.nist.gov/pml/time-and-frequency-division/radio-s...

When I was a kid my dad had built a Heathkit multiband radio receiver[1] and we used that station to set our clocks at home.

1. https://commons.wikimedia.org/wiki/File:Vintage_Heathkit_16-...

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.

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.

You're correct it never has. GPS time started 6 Jan 1980 and has ignored every leap second since.

The painful fact is that it does include the leap seconds before January 6th 1980. Makes it messy to convert between UTC and GPS time.

I think all the online converters I found a couple of years ago failed to get this right.

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.

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

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.

NIST has offered telephone time for as long as I can remember (40+ years). You can reach it at: 303-499-7111

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.

Worked for me just now. It clicks for a bit than says "US Naval Observatory Master Clock" + the time.

For me it was ringing for 2 minutes before I gave up. I have the timestamp on my phone to prove it.

But then again Sprint may just be trash at providing phone service yet again. I may try again from a VOIP provider later.

> Navy continues to offer a telephone time service (202-762-1401) while NIST does not.

But on this page https://www.nist.gov/pml/time-and-frequency-division/radio-s... NIST shows a working phone number...

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.

Are those the last two characters of stringing NaN?

yes!

I wonder what the deal with them refreshing every 10 minutes is... This is at the bottom:

setInterval(function() {

   location.reload();

}, 600000);

My only guess is accounting for local clock drift.

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.

Sounds like pointless astronaut engineering. What problem do you think that would solve?

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.

They didn't upgrade their JS apparently. Could have been es6 arrow notation. :)

A lot of people still use IE11 which doesn't support arrow notation :/

Sadly, IE 11 isn't going away any time soon.

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.

Why does time.gov need analytics? None of the usual reasons businesses cite as requiring them are valid here.

The accountability of government to the people would be the primary reason, the idea being to show the value for the money you're being taxed.

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

Interesting stuff. Surprised to see such tech literacy on the White House’s website.

The fed is also responsible for making ghidra. Not everyone working for the fed is a lawyer.

You shouldn't be. There are incredibly competent technologists currently in positions to deliver.

https://www.usds.gov/

https://18f.gsa.gov/

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:

https://github.com/18F/analytics.usa.gov

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.

You can view dot gov analytics here, by the way.

https://analytics.usa.gov/

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)

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

Very interesting, thanks for the color-blindness link.

> 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.

Pleased to see they retained support for properly displaying :60 seconds during the leap second.

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.

How come it uses AM and PM rather than 24-hours?

Because that's the custom in the US.

Using 24 hours is "military time" there.

You can switch to 24 hour format, but I can't confirm it works, because it's AM and it still does say AM.

There is a toggle for switching it to a 24hour clock.

Here's what the site looked like previously, a classic design: https://images.mix.com/production/b0/9f/b09f278d6474c4ac543b...

With a giant Texas flag down the side. I wonder why Texas.

As a Texan I'm offended it's not obvious why.

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.

Just before this upgrade today, it looked like that?

Literally yes, though it was worse some number of years ago.

It looked precisely like this, but was a java applet.

I believe it was Flash for a while, and then eventually the Flash app was automatically converted to "HTML5".

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!

A fun copy-paste goof in one of the CSS files: https://time.gov/css/NIST-styles.css has the footer text from github.com at the bottom.

A reminder to always click to raw format before copying code from GitHub.

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.

Do they have the audio version that is broadcast on AM?

time.is/ is a damn near perfect website. Doing one thing really well.

I only wish it had more date display options: day number and ISO8601 Week Number.

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.

It says my mac is off by nearly a full second, and sntp from the command line agrees.

  2020-02-07 20:49:08.720955 (+0800) +0.949762 +/- 0.732397 pool.ntp.org 108.59.2.24 s2 no-leap

Why is the clock discipline on macos so bad?

ETA: my local linux box by contrast is off by 1ms.

  2020-02-07 20:54:23.770052 (+0800) +0.000570 +/- 0.019234 pool.ntp.org 50.205.244.108 s2 no-leap

My Windows 10 was off by 3.3sec and just checked when it was last sync (12hours ago).

Did the resync and now just off by 0.08sec

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.

Am I correct in inferring that you're saying the system time on your machine has lost 2 seconds since you last synchronised it with time.gov?

Over what time period did the slippage occur?

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.

I can't load time.gov right now but time.is says my Mac is only off by 3ms (±17ms).

My Android is off by 1.744. I wonder if it could be used for tracking as additional bits of info

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.

https://www.nist.gov/pml/time-and-frequency-division/about-t...

> It is estimated that the one-half of the round-trip delay happens in each direction.

Anyone know how true this is? Particularly for mobile/asymmetric bandwidth connections - what might the errors bars be?

kube-system nailed it, though if you want to see the JS in action, visit https://time.gov/scripts/zzz__0fd3fed7f945928bf590af174cd541...

and grep for realTimeDif

Nice. No React or Angular here! Wonder if that's normal for government projects?

Yes, government things are usually required to work for more than a few years without requiring a total rewrite.

TIL the Navajo nation (in North East Arizona) recognizes daylight savings while the enclaved Hopi nation does not along with the rest of Arizona.

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.

We made it :)

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.

Phone timer isn't allergic to DST, for the future.

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.

It's a lot better than before but still not 100% polished. E.g. the bottom left of the footer shows undefined #responseTime

https://i.imgur.com/703v1cC.jpg

Screenshot as of 8:57pm UTC-5 if it's down for you:

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

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.

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...

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’m fairly sure the JS standard guarantees that no layouting (or any form of rendering) would happen mid function execution.

I think the JS standard doesn't have any notion or layout of rendering. Which part of the standard are you referring to?

You sure you're not looking at the "Your Device's Clock" part of the page? All mine (except that nice little box) are in sync.

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 ;)

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

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.

The “windows protocol” has been NTP since the year 2000.

Before that there was NET TIME which ran over SMB and probably still works because backwards compatibility is what built the MSFT empire.

Only sorta related but that map doesn’t show this interesting detail which I experienced first hand:

The Navajo Nation Reservation is on a different time zone than the state it is mostly inside.

But the Hopi Reservation is entirely contained within the Navajo, and is on a different time zone.

When we drove through that region my phone just freaked out, switching times back and forth arbitrarily.

And the hotel had three clocks in the lobby for clarification.

Mobile safari says can’t connect to the server. Is it down or does it not have a web interface ?

Desktop Safari says it won't connect either, but if I open it in Chrome, it loads... odd. Wonder what could be causing that? Makes no sense to me.

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.

Odd. It appears to show all of TX in central time. I thought the Western tip (El Paso, basically) was Mountain.

Edit: fixed now. Quick work for a Friday night!

Unless something's changed, you appear to be correct (edit: as of just before 9pm eastern - https://i.imgur.com/dFrM24l.jpg)

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!

It's corrected now.

Hello NIST employee watching this thread. Nice quick turnaround!

Thanks! And you fixed FL :)

Really great refresh from the old version of the site.

I never realized the time zones cut through so many states.

Stop being so jealous of our Canadian version: https://nrc.canada.ca/en/web-clock/

Ok. Done being jealous. Thx

doesn't even work without enabling third party JS

Yup, I noticed that myself. If it doesn't work with uMatrix … then it doesn’t work.

Hardly "third-party", it's just a second domain of the same institute.

Whatever they’re doing, it’s still “third-party” enough that it won’t work with mobile Safari (or perhaps Safari’s default settings).

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.

Didn't this used to be a java plug-in?

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".

They made it a standard html/js front-end app that precisely mimicked the java applet some years ago, but they ditched that entire UX today.

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.

My device's clock is off by 1 hour.

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.

https://chronograph.io

Old school nerds remember setting their calculator watches by calling into the us naval observatory master clock.

https://www.usno.navy.mil/USNO/time/telephone-time

TRUE old school nerds remember setting their watches by tuning to WWV/WWVH :)

I remember listening to WWV for a leap second when I was in high school. :D

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.

Firefox adds about 100 milliseconds.

The code generating this is un-minified and loaded from here:

https://time.gov/scripts/zzz__0fd3fed7f945928bf590af174cd541...

It's basically:

    timeDotGov.data.realTimeDif = 
    timeDotGov.data.serverTime - 
    timeDotGov.data.responseTime;

with added corrections. Grep for

    realTimeDif

to see all of it.

Could this be used for fingerprinting?

Yes.

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.

Considering what it [looked like 1 week ago](https://web.archive.org/web/20200129180342/https://time.gov/), I'd say this is an improvement.

My favorite part is "THE OFFICIAL U.S. TIME".

No messing around.

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!

Tried it, similar for me! Interesting find

So why is my Windows 10 clock over a second fast? Isn't NTP accurate to within a fraction of a second?

Would like to understand too. On a new android 10 phone it was 1.7 seconds. Not that large, but in computer/processing time it is pretty large.

My iPhone is showing 0.024s for an extra data point.

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.

Last I knew, Windows uses SNTP, not NTP (unless you explicitly install an NTP server or modify the registry to tell it to use NTP).

SNTP is notoriously less accurate but is usually "good enough".

Is it supposed to be pulsing/twitching constantly? (using Edge-Chromium)

A functional and easy to read government website?

Well that’s not something you see every day.

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.

If you append `?t=24` to the URL it shows 24-hours clocks.

Aw, I quite liked the simple design of the old version.

I wonder how they lined up each of the time box to each color gradient at diff resolutions. From what I see, that gradient and map is a single pic.

Can you change the link to https://? Can't connect over http.

I know Arizona doesn't observe DST, but how come the whole state isn't shaded? Does the Grand Canyon observe DST?

I think parts of the Navajo Nation does observe DST.

This is correct. Additionally, the Hopi Reservation, an enclave within the Navajo Nation, does not observe DST, hence the smaller shaded region.

Oh wow. It's really cool that the developers put the effort in to denoting the difference.

Thank you!

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...

There is also a Navajo enclave within that Hopi reservation/enclave: http://mm.icann.org/pipermail/tz/2016-May/023665.html

They broke my workflow[1].

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/

They firewalled 123 but not 80? I’m not a cybersecurity authority, but that seems insane.

Well 443 actually.

Map gets me wondering exactly which meridian within these time zones does solar noon match up with clock noon.

The site appears to be down now.

That actually looks good while still being functional. It even works with IE11

Awesome! I go to that site every couple weeks to set my watch!

I'd like this visualisation for the world!

Love how it says undefined at the very bottom.

Puerto Rico should be added

It is, look on the bottom right.

Isn't it odd not to have an HTTP to HTTPS redirect? I assumed I was having DNS issues.

aaaand it's down.

Off by +0.096 s

Some of the last few bits of local government control shown in the poor overlap of time zones and state boundaries.

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.

There's a value at the bottom of the black box on the right stating your computers drift from NIST.

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.

Whoever developed the javascript could benefit from a formatter. Also, synchronous ajax calls?

Reply on news.ycombinator.com