3 ms·

I wonder what the deal with them refreshing every 10 minutes is... This is at the bottom: setInterval(function() { location.reload(); }, 600000);

eganist 7y ago
My only guess is accounting for local clock drift.
kijin 7y ago
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.
- corylulu 7y ago
  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.
  - kortilla 7y ago
    Sounds like pointless astronaut engineering. What problem do you think that would solve?
  - ascar 7y ago
    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.
datafatmunger 7y ago
They didn't upgrade their JS apparently. Could have been es6 arrow notation. :)
- collinmanderson 7y ago
  A lot of people still use IE11 which doesn't support arrow notation :/ Sadly, IE 11 isn't going away any time soon.
PoorlyDirected 7y ago
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.

eganist 7y ago

My only guess is accounting for local clock drift.

kijin 7y ago

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.

corylulu 7y ago
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.
- kortilla 7y ago
  Sounds like pointless astronaut engineering. What problem do you think that would solve?
- ascar 7y ago
  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.

datafatmunger 7y ago

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

collinmanderson 7y ago
A lot of people still use IE11 which doesn't support arrow notation :/ Sadly, IE 11 isn't going away any time soon.

PoorlyDirected 7y ago

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.