GNU bug report logs - #11866
date doesn't accept 61-sec. minutes

Previous Next

Full log

View this message in rfc822 format

From: Juergen Heine <j.heine <at> qvs-deutschland.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: 11866 <at> debbugs.gnu.org
Subject: bug#11866: command date doesn't accept 61 sec. minutes
Date: Thu, 05 Jul 2012 22:05:17 +0200

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
juergen.heine <at> qvs-deutschland.de

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.