| |||||||||||||
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)Posted Jul 2, 2012 16:24 UTC (Mon) by Baylink (subscriber, #755)In reply to: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) by Baylink Parent article: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)
To clarify: it appears to me (based on the available evidence at the moment) that the fundamental underlying cause of this failure is a failure by the people who need to to understand that 235960 is a valid timestamp.
ISO8601 actually permits 60 as a valid seconds count, for precisely this reason.
https://en.wikipedia.org/wiki/ISO_8601
I had thought that it, for some reason, permitted 61, too, but I was worng.
(Log in to post comments)
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 4, 2012 7:12 UTC (Wed) by butlerm (subscriber, #13312) [Link]
The cause is not a failure in understanding, it is a failure in implementation. The kernel does not track time in hours, minutes, and seconds, but it (regrettably) does track time using a standard encoding designed around the assumption that leap seconds can be profitably ignored.
Changing the kernel's internal time base to use something TAI derived instead of UTC derived is probably the only way to fix this problem reliably. The downside is that means the kernel would have to maintain a leap second table and convert back and forth between POSIX time and linear time where necessary.
|
|||||||||||||