Tom Van Baak wrote in <F98D0943EDD5418E8C5594F14091D0C1@pc52>: ... |Now back to Google and its ~24 hour smear. One feature of their approach \ ... |I'm wondering how the LEAPSECS crowd feels about long or short smears. \ |One way to measure this is the area under the curve. For a 24 hour \ |smear the |error| ramp goes from 0 to 0.5 to 0 over 24 hours; so that's \ |an integrated error area of 6 hour-seconds. For a short smear it's \ |more like 1 second-second. | |/tvb | |[1] https://en.wikipedia.org/wiki/Lavet-type_stepping_motor |[2] https://en.wikipedia.org/wiki/Quartz_clock |[3] http://leapsecond.com/pages/32kHz/
My personal opinion is that the entire complex stinks. It is not about smear-x or smear-y but about notification as such. It is unfortunate that a non-monotonically increasing timestamp is distributed: this is not "normal" in respect to nature. At least not on my level of physics, space people may have a different view. What would be needed would be a distribution of TAI (i say TAI but mean a timestamp with properties that can be dealt with), with a permanent distribution of an offset to civil time UTC. And a service that can be queried to gain the list of UTC adjustments easily. Say, NTP/[D]TLS and some DNS record service, as has come up on this list. I think it is completely ridiculous that the time is off for 24 hours, or six hours, or whatever. I still like the UTS proposal[1], but i would have nothing against a smaller fraction as long as the clock monotonically increases and (software) consumers have a realtime clock or better TAI clock available. It is about knowledge, DCF77 for example reports about leap seconds one hour in advance only, and has forgotten about the fact one second thereafter. I mean, yet this is still enough to smear one second. With a normal analog watch, i come back the next morning and see i am off one second, but currently i have no idea at all why this has happened. At least not via NTP as normally distributed, unless i am mistaken, which can very well be the case since i am sitting on RFC 2030, which extends DCF77 in sofar as the info is available the entire day long. This is not why i need, what i would need in addition would be a leap info bit months surrounding the leap, and an additional query i can perform which gives more leap info on explicit request. [1] https://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
