[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11866: command date doesn't accept 61 sec. minutes
From: |
Juergen Heine |
Subject: |
bug#11866: command date doesn't accept 61 sec. minutes |
Date: |
Thu, 05 Jul 2012 22:05:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16 |
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
address@hidden
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