On 2022-02-22 01:33, Keith Lofstrom wrote: > I'm running this script in an xterm: > > while true; do date -u; sleep 10 ; done > > Tuesday Feb 22 afternoon, it may emit: > > ... > Tue Feb 22 22:22:12 UTC 2022 > Tue Feb 22 22:22:22 UTC 2022 > Tue Feb 22 22:22:32 UTC 2022 > ... > > Them's a lotta 2s, and there won't be more 2s for 200 years. > And that will be a Friday, not a twos day. > > Or not, the stuff besides the "sleep 10" will take a few > milliseconds as well.
I got my screen capture. I was a wee bit late, perhaps 222 milliseconds? :-) I ran the script for a day; it picked up 6 seconds delay added onto the 8640 "sleep 10"s executed. Given that the day overlapped evening system backups, not bad. An older machine with 8 CPU cores, typical load average during backups about 1.5. I restarted before my measurement. BTW, I've learned that you can add extra formatting to "date": date -u +"%F %T.%3N" gives the milliseconds UTC, date -u +"%F %T.%9N" gives the nanoseconds UTC. The obsessive will argue whether the speed-of-light UTC delay correction should be computed for optical fiber with router delay, vacuum speed of light around 120 degrees of Earth circumference, or the diagonal through the Earth's core. More than milliseconds, in any case. Regards Mike's comment about 22:22 aka "10:22 PM": PLUG is a multi-time-zone group, and Linux spans the globe. The relevant time for "when is 22:22:22" is UTC, formerly "Greenwich Time". We share UTC with the world. UTC is no longer defined by the position of Greenwich, currently migrating northwest a few millimeters per year. We can use PST/PDT to schedule local meetings, but global events like Tue Feb 22 22:22:22 UTC 2022 is the same exact time everywhere. Even on Voyager 1, now 18 light hours and 156 astronmomical units away, 44 years after launch. Years hence, the world will be "24 hours", and we will choose our personal time zone and circadian rhythm based on the people we network with. Read Cory Doctorow's novel "Eastern Standard Tribe". As a late night geek, personal time zone edges is closer to Japan :-) Regards obsessive: Semi-relevant: A few years ago, I spent an afternoon with Eric Raymond at his home in Malvern, PA. ESR was working on atomic clock USB3 dongles for "top tier" synchronization of the internet, currently synchronized to the purposely degraded time signal from GPS. ESR's goal was to "de-degrade" GPS back to NIST nanosecond accuracy. BTW, an atomic clock now fits on a tiny chip and a small circuit board, though it still costs a few thousand dollars. Semi-semi-relevant: In May 2018, Dr. David Wineland presented the annual Portland State University Gurevitch Lecture, describing his Nobel-Prize-winning atomic clock experiments at NIST Boulder. 17 decimal place accuracy. One of his experiments was synchronizing two identical clocks, then jacking one up a meter. After a few weeks, the "low" clock had accumulated about 1000 less "ticks", verifying the prediction of general relativity that time runs slower, deeper in a gravity well. I talked with him about what's next. He's at University of Oregon now (your shoe dollars at work), and we discussed how to get to 20 decimal place accuracy. Semi-practically-relevant: I'm attempting to understand how bitcoin blockchain calculations adjudicate time delay. I suspect there are some exploitable corner cases if two leading contenders for a win have different speed-of-light delays from the win-determining process. Worse, I suspect there are ways this can be gamed with "opaque hardware" bitcoin mining engines, partly "powned" by the hardware designer, not the mining engine purchaser. If all you have is the Verilog, but you can't read the chip transistors, you don't have the actual "source code". I don't care much about bitcoin, but two friends are 7-digit-dollars invested in it, and I don't want them hurt. So yes, time obsession does have practical consequences. If one friend loses his wealth and his yacht, there goes my spare bedroom. :-/ Keith -- Keith Lofstrom [email protected]
