Reminds me of a highly accurate clock used in broadcasting. This clock sends out a time signal around the building to various clocks on walls and equipment, e.g. 'VT machines' (or whatever is used now).
I had the pleasure of adjusting this clock for GMT/BST twice a year. The great thing about this clock was that it did not actually tell the time itself. One would have to walk out of the machine room and through a couple of corridors, up a flight of stairs and into a gallery to actually see the alleged time with one's own eyes. All it had was a MODEM socket hidden in the back of a 19U rack, with the wires in U.S. configuration rather than what we have in the U.K.
So, to change the time you could 'conveniently' solder up a lead that would actually connect to the box, telnet in, remembering to get the password right, then set the time zone using the obscure command procedure provided.
This would be a simple enough task, however, there would be two of these clocks and they would talk to each other. So changing the time on one would not be good enough, the other would correct it or set it ahead/back by another hour. For added convenience the other 'master' clock would be in an entirely different part of the building and need to stay 'on' the whole time.
When it comes to extreme horology, I think that the most stupendously over-the-top accurate timepieces should not actually be able to tell the time with something as cheap and tacky as a display. If the time does have to be displayed then it should be in UNIX epoch time as that is the most convenient for all concerned.
Are there any experts on the subject that can tell how accurate these documentaries are? I find it fascinating, but am always sceptical about the simplifications they might use.
If the time does have to be displayed then it should be
in UNIX epoch time as that is the most convenient for all
concerned.
Unix time isn't monotonic: leap seconds are added by double-spending: 915148800.00 occurred twice. This means it's ambiguous, that unix timestamp refers to two different points in time, one second apart.
I am actually very pleased to have learned that snippet of useful information!
FYI when I wrote my comment I had just added an attribute to a product catalog that uses [very large number] - [product creation date in epoch format] so that I could have a latest added as the sort order without having to go through the bother of having DESC on my SQL query.
I assure you that only on HN could you find someone that is delighted to know about how 'unix time is not monotonic'... - thanks!
I had the pleasure of adjusting this clock for GMT/BST twice a year. The great thing about this clock was that it did not actually tell the time itself. One would have to walk out of the machine room and through a couple of corridors, up a flight of stairs and into a gallery to actually see the alleged time with one's own eyes. All it had was a MODEM socket hidden in the back of a 19U rack, with the wires in U.S. configuration rather than what we have in the U.K.
So, to change the time you could 'conveniently' solder up a lead that would actually connect to the box, telnet in, remembering to get the password right, then set the time zone using the obscure command procedure provided.
This would be a simple enough task, however, there would be two of these clocks and they would talk to each other. So changing the time on one would not be good enough, the other would correct it or set it ahead/back by another hour. For added convenience the other 'master' clock would be in an entirely different part of the building and need to stay 'on' the whole time.
When it comes to extreme horology, I think that the most stupendously over-the-top accurate timepieces should not actually be able to tell the time with something as cheap and tacky as a display. If the time does have to be displayed then it should be in UNIX epoch time as that is the most convenient for all concerned.