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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11866 in the body.
You can then email your comments to 11866 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juergen Heine <j.heine <at> qvs-deutschland.de>
To: bug-coreutils <at> gnu.org
Subject: command date don't accept 61 sec. minutes
Date: Thu, 05 Jul 2012 10:15:41 +0200

According to The International Earth Rotation Service (IERS) we have
"Leap Seconds" included in our UTC time.

Please refer http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat .

~ snip ~
 A positive leap second will be introduced at the end of June 2012.
 The sequence of dates of the UTC second markers will be:

 2012 June 30, 23h 59m 59s
 2012 June 30, 23h 59m 60s
 2012 July 1, 0h 0m 0s
~snap~

The command 'date' doesn't calculate it.


Test:

$ date +%s -d "2012-06-30 23:59:60"
date: invalid date `2012-06-30 23:59:60'


Tested version:

date (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

-- 
Juergen 'sysdef' Heine, gnu-date <at> sysdef.de

Message #8 received at 11866 <at> debbugs.gnu.org (full text, mbox):

From: Juergen Heine <j.heine <at> qvs-deutschland.de>
To: 11866 <at> debbugs.gnu.org
Subject: Re: bug#11866: Acknowledgement (command date don't accept 61 sec.
	minutes)
Date: Thu, 05 Jul 2012 18:13:39 +0200

Hello,

can you please do me a favor and correct the typo in the title?


don't -> doesn't


Thank you for the GNU system!


-- 

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

Message #11 received at 11866 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Juergen Heine <j.heine <at> qvs-deutschland.de>
Cc: 11866 <at> debbugs.gnu.org
Subject: Re: bug#11866: command date don't accept 61 sec. minutes
Date: Thu, 05 Jul 2012 10:39:26 -0600

[Message part 1 (text/plain, inline)]

retitle 11866 date doesn't accept 61-sec. minutes
tag moreinfo
thanks

On 07/05/2012 02:15 AM, Juergen Heine wrote:

>  A positive leap second will be introduced at the end of June 2012.
>  The sequence of dates of the UTC second markers will be:
> 
>  2012 June 30, 23h 59m 59s
>  2012 June 30, 23h 59m 60s
>  2012 July 1, 0h 0m 0s
> ~snap~
> 
> The command 'date' doesn't calculate it.

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
- _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 - 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.

On 07/05/2012 10:13 AM, Juergen Heine wrote:> Hello,
>
> can you please do me a favor and correct the typo in the title?
>
>
> don't -> doesn't

Done.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #18 received at 11866 <at> debbugs.gnu.org (full text, mbox):

From: Juergen Heine <j.heine <at> qvs-deutschland.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: 11866 <at> debbugs.gnu.org
Subject: Re: 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

Message #23 received at 11866-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Juergen Heine <j.heine <at> qvs-deutschland.de>
Cc: Eric Blake <eblake <at> redhat.com>, 11866-done <at> debbugs.gnu.org
Subject: Re: bug#11866: command date doesn't accept 61 sec. minutes
Date: Thu, 05 Jul 2012 16:16:49 -0700

On 07/05/2012 01:05 PM, Juergen Heine wrote:
> 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"?

Sure, I added the following and am marking this as done.


From bfda96e0ac5552bb1784f5e1dc311918ce077d50 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 5 Jul 2012 16:11:49 -0700
Subject: [PATCH 2/2] doc: document leap seconds better

* doc/coreutils.texi (touch invocation, Time conversion specifiers)
(Options for date, Examples of date): Index "leap seconds" and
improve their documentation a bit.
---
 doc/coreutils.texi |   39 ++++++++++++++++++++++++++++++++++++++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3c7f4e5..751a920 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -10493,13 +10493,15 @@ If @var{file} is a symbolic link, the reference timestamp is taken
 from the target of the symlink, unless @option{-h} was also in effect.
 
 @item -t [[@var{cc}]@var{yy}]@var{mmddhhmm}[.@var{ss}]
+@cindex leap seconds
 Use the argument (optional four-digit or two-digit years, months,
 days, hours, minutes, optional seconds) instead of the current time.
 If the year is specified with only two digits, then @var{cc}
 is 20 for years in the range 0 @dots{} 68, and 19 for years in
 69 @dots{} 99.  If no digits of the year are specified,
 the argument is interpreted as a date in the current year.
-Note that @var{ss} may be @samp{60}, to accommodate leap seconds.
+On the atypical systems that support leap seconds, @var{ss} may be
+@samp{60}.
 
 @end table
 
@@ -14243,11 +14245,13 @@ locale's 12-hour clock time (e.g., @samp{11:11:04 PM})
 @cindex epoch, seconds since
 @cindex seconds since the epoch
 @cindex beginning of time
+@cindex leap seconds
 seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC@.
 Leap seconds are not counted unless leap second support is available.
 @xref{%s-examples}, for examples.
 This is a @acronym{GNU} extension.
 @item %S
+@cindex leap seconds
 second (@samp{00}@dots{}@samp{60}).
 This may be @samp{60} if leap seconds are supported.
 @item %T
@@ -14650,12 +14654,15 @@ See also @ref{Setting the time}.
 @cindex UTC
 @cindex Greenwich Mean Time
 @cindex GMT
+@cindex leap seconds
 @vindex TZ
 Use Coordinated Universal Time (@acronym{UTC}) by operating as if the
 @env{TZ} environment variable were set to the string @samp{UTC0}.
 Coordinated
 Universal Time is often called ``Greenwich Mean Time'' (@sc{gmt}) for
 historical reasons.
+Typically, systems ignore leap seconds and thus implement an
+approximation to UTC rather than true UTC.
 @end table
 
 
@@ -14806,6 +14813,36 @@ date -u -d '1970-01-01 946684800 seconds' +"%Y-%m-%d %T %z"
 2000-01-01 00:00:00 +0000
 @end smallexample
 
+@item
+@cindex leap seconds
+Typically the seconds count omits leap seconds, but some systems are
+exceptions.  Because leap seconds are not predictable, the mapping
+between the seconds count and a future timestamp is not reliable on
+the atypical systems that include leap seconds in their counts.
+
+Here is how the two kinds of systems handle the leap second at
+2012-06-30 23:59:60 UTC:
+
+@example
+# Typical systems ignore leap seconds:
+date --date='2012-06-30 23:59:59 +0000' +%s
+1341100799
+date --date='2012-06-30 23:59:60 +0000' +%s
+date: invalid date '2012-06-30 23:59:60 +0000'
+date --date='2012-07-01 00:00:00 +0000' +%s
+1341100800
+@end example
+
+@example
+# Atypical systems count leap seconds:
+date --date='2012-06-30 23:59:59 +0000' +%s
+1341100823
+date --date='2012-06-30 23:59:60 +0000' +%s
+1341100824
+date --date='2012-07-01 00:00:00 +0000' +%s
+1341100825
+@end example
+
 @end itemize
 
 
-- 
1.7.6.5

Previous Next

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