On 05/07/12 18:39, Eric Blake wrote: > retitle 11866 date doesn't accept 61-sec. minutes
thank you for the correction. > The command 'date' doesn't have any control over whether your system is > configured to honor or ignore leap seconds. Some systems are > intentionally configured to ignore leap seconds (for a famous example, > read > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html thank you very much for leading me to that very interesting solution to solve the technical problems it can cause. > - _most_ of google's computers are programmed to ignore leap seconds, by > instead providing a change in just the few computers that control their > internal NTP synchronization to smear the leap second over the course of > a day). > If your system has leap-second accounting turned on, then 'date' can > properly use it. If your system has leap-second accounting turned off, > then 'date' properly fails because your system is configured to reject > that date. But there is nothing coreutils can do about it, other than > obey the settings particular to your system. > You didn't mention what system you are on Debian GNU/Linux 6.0 stable/Squeeze Linux Kernel: 2.6.32 Arch: amd64 / x86_64 > if we knew that information, > we might be able to help you figure out whether there is an easy way to > configure your system to use leap seconds (but be careful what you wish > for - there was a bug in recent Linux kernels that manifested itself as > a 100% load inside an futex on machines configured to honor leap > seconds; all the more reason why the leap smear technique is so > appealing to organizations that can tightly control how time is > synchronized within their own network). Therefore, I am tagging this > bug as 'moreinfo', but we will probably close it out as 'notabug' in a > few more days. I think re-configuring the system will not correct the drift between the two timelines. It will just set/correct the UTC clock in time. So the situation looks like: ---- Leap Seconds and UNIX timestamps * Unix timestamp time line ignores the leap seconds because there is no reason it should. There is no relation to earth rotation or any calendar system. * There is no timestamp for leap seconds. The leap seconds are increasing the speed of the UTC time line to correct the faster earth rotation. * Leap seconds are (in contrast to calendar leap days) ignored by unix timestamp time line. * The definition "seconds since EPOCHE, 1970-01-01 00:00:00" is incorrect when looking at your UTC time because there is a not calculated drift of about 30 seconds. * 'date' is correct and wrong at the very same time with "2012-06-30 23:59:60 doesn't exist" because the system is UNIX-time based and the leap second is missing in the timestamp timeline but the time exists in the UTC stream we are asking for. ---- If i'm correct, can we add this information to the manual for people who don't understand the simple line "leap seconds are getting ignored"? And by a chance a "please RTFM, abstract 'Leap Seconds'" instead of "date is incorrect"? Greetings from Germany! -- Mit freundlichen Grüßen / Sincerely i. A. Juergen Heine [email protected] QVS GmbH Lange Laube 18 D-30159 Hannover http://www.qvs-deutschland.de Tel: 0511 790 201 60 Fax: 0511 790 201 65 FreeCall: Tel: 0800 24 400 24 Fax: 0800 24 400 25 Amtsgericht Hannover HRB 203111 Steuernr. 25/203/58348 Ust-IdNr. DE260351579 Geschäftsführer: Prof. Dr. Josef Kraus, Stefan Klotz
