| |||||||||||||
Leaping seconds and looping serversLeaping seconds and looping serversPosted Jul 3, 2012 23:53 UTC (Tue) by xman (subscriber, #46972)In reply to: Leaping seconds and looping servers by drag Parent article: Leaping seconds and looping servers
The kernel's use of UTC time was why ntpd had to do what it did, which exposed the faulty logic.
TAI is the way to go.
(Log in to post comments)
Leaping seconds and looping servers Posted Jul 4, 2012 3:28 UTC (Wed) by drag (subscriber, #31333) [Link]
Does anybody actually use TAI for anything?
As far as scientific time keeping it's already been found to be fundamentally flawed due to the fact that they didn't take the effect of gravity into it. and is probably going to be replaced by something else eventually that is adjusted for altitude.
Leaping seconds and looping servers Posted Jul 4, 2012 13:26 UTC (Wed) by andreasb (subscriber, #80258) [Link]
Going by what's on the Wikipedia page, it has been corrected for altitude (normalized to mean sea level) since 1/1/1977. The former uncorrected TAI got the new name EAL.
Leaping seconds and looping servers Posted Jul 4, 2012 18:32 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> Does anybody actually use TAI for anything?
GPS does. The GPS timestamp is TAI with a fixed offset.
Leaping seconds and looping servers Posted Jul 17, 2012 17:59 UTC (Tue) by Baylink (subscriber, #755) [Link]
No; that's factually incorrect, I'm afraid.
The problem here is not the *choice of timescale*: UTC is monotonic even over leap seconds; 58, 59, 60, 00.
The *problem* is that the kernel isn't following UTC *either*; not if it's ticking backwards. It's that *ticking backwards* part that is the problem, and I've yet to see a truly compelling reason why it should do so.
|
|||||||||||||