bug#11866: command date don't accept 61 sec. minutes

[Eric Blake]

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature