"%S	Second as a decimal number [00,61].	(2)
(2) The range really is 0 to 61; this accounts for leap seconds and the 
(very rare) double leap seconds."

That is wrong. There NEVER can be two leap seconds in one moment, since UTC 
time keep the difference between UTC and UT1 from exceeding ±0.9 s.

Leap seconds occur only at the end of a UTC month, and have only ever been 
inserted at the end of June 30 or December 31.

So, 61 is wrong, real seconds range from 0 to 60 inclusive.

OP does not have the reference, but the issue is apparently in the time
and datetime modules documentation:

http://docs.python.org/dev/library/time.html#time.strftime
http://docs.python.org/dev/library/datetime.html#strftime-behavior

Note that datetime's doc is twice incorrect because leap seconds are not
supported by the datetime module at all:

>>> from datetime import *
>>> time(23,59,60)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59
>>> datetime.strptime('20000101T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

On the other hand, the time module allows full [00,61] range:

>>> [time.strftime('%S',time.strptime(x, '%S')) for x in ('00', '61')] 
['00', '61']

so this is implementation rather than documentation issue.

There no leap second in 2000th.
But correct time request fails:
>>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

On Mon, Apr 7, 2008 at 3:42 PM, Anton Fedorov <report@bugs.python.org> wrote:

>  There no leap second in 2000th.

I was just too lazy too look up the leap second year, but datetime
module knows nothing about leap seconds, so I did not expect different
behavior for years 1995 and 2000.

>  But correct time request fails:
>  >>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')

ditto

Isn't the bug here rather that strptime doesn't allow leap seconds?

On Wed, Apr 9, 2008 at 2:49 PM, Georg Brandl <report@bugs.python.org> wrote:

>  Isn't the bug here rather that strptime doesn't allow leap seconds?

This is not specific to strptime.  The datetime module does not allow
leap seconds:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

This is intentional and documented. Or maybe I don't understand your question.

Okay, sorry that I made uninformed guesses :)

The 'double leap second' issue has been around a long time and is part
of the Posix standard (for some background see
http://www.ucolick.org/~sla/leapsecs/onlinebib.html, specifically the
section named 'Unix system time and the POSIX standard').  This document
notes that the double leap second was still in the standard in 1997, and
according to Wikipedia that is after the last revision of the standard,
so presumably it is still there.

Therefore the time documentation of strftime is correct, since my
understanding is that time is a wrapper around the Posix time functions.
 The datetime docs, on the other hand, are misleading in the strftime
documentation.  I've attached a doc patch to have the note clarify that
datetime does not consume or produce leap seconds.

Doc patch applied in r71037.

I am reopening this issue because the following note is still not entirely correct:

"""
The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard ...
""" - http://docs.python.org/library/datetime.html#strftime-and-strptime-behavior


First, the latest POSIX standard (IEEE Std 1003.1, 2004 Edition) defines seconds range as [0, 60]. 

http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

Second, AFAIK, the only way to produce tm structure with tm_sec = 60 using a POSIX function is to explicitly pass "60" to a "%S" field in strptime. Other functions that fill tm structure, such as localtime or gmtime will never produce tm_sec = 60.  This is important because in the current form the comment suggests that the common recipe of passing first six elements of time.struct_time() to datetime constructor is unsafe while it is only unsafe if the time information comes from a non-POSIX system.

Third, POSIX is not a relevant standard for Python.  I have not seen any statement of python compliance to any version of Posix.  The relevant standard, I believe is C89:

"""
 Python now must be compiled with C89 compilers (after 19 years!).
""" - http://docs.python.org/whatsnew/2.6.html

While strictly speaking this is not a compliance statement, at least it has Python and C89 in the same sentence. :-)

AFAIK, the C89 standard does allow double leap seconds.  It may also allow compliant systems to produce leap second times from localtime() or gmtime(), but I don't have access to the text at the moment.  If this is true, the only fix required is s/POSIX/C89/g.

The C89 draft as available through a Wikipedia link, http://flash-gordon.me.uk/ansi.c.txt, specifies tm_sec range as [0, 60].  Although it looks like the range has been extended in the published version.  A discussion on comp.std.c describes the situation as follows:

"""

The "double leap second" is complete nonsense. It never existed outside the 
ANSI C standard and never will. It was introduced by the ANSI C 89 committee 
to document its problems understanding UTC issues. Someone heard that there 
are two prefered dates for leap seconds per year and this got munched up to 
the false rumour that UTC days can be up to 86402 seconds long. The 
definition of UTC, which requires that |UTC-UT1| < 0.9 s all the time, 
obviously makes double leap seconds mathematically impossible. 
"""

The latest publicly available standard that I was able to find that specifies [0, 61] range was "The Single UNIX ® Specification, Version 2" from 1997: http://pubs.opengroup.org/onlinepubs/007908799/xsh/time.h.html

Note that this range has been recognized as a mistake by Open Group:

"""
Problem:

 The valid range of seconds is no longer 0-61, a range chosen
 to accomodate the mythical double leap second.

 The correct range is 0-60 seconds.

 This has been fixed elsewhere in 1003.1-200x already.  See for
 instance <time.h>.

 Action:

 Change range to 00-60 seconds.

 Search for any other places where the range is wrongly given as 0-61
 and fix them too.
 [Ed recommendation: Accept as marked
 make the change , and add a note to the CH
 that
 The description of %S is updated so the valid range is 00-60 rather
 than 00-61.

 A search was done of the draft for other occurrences of 61 and none
 found.  ]
"""  http://www.opengroup.org/austin/docs/austin_77r1.txt

Compliance with the mistakes in old versions of various standards, does not seem like a valid goal for Python, but until a system is reported that misbehaves when tm_sec = 61 is passed to strftime, I don't see a compelling reason to change Python behavior.  On the other hand, the documentation should not refer to bogus standards, so I suggest to change 

"""
The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard ...
"""

to 

"""
The range really is 0 to 61; tm_sec = 60 may be necessary to represent an occasional leap second and tm_sec = 61 is supported for historical reasons.
"""

Committed in revision 87910.

resolution: fixed
stage: needs patch -> resolved

assignee: belopolsky
versions: + Python 3.2, Python 3.3
nosy: + mark.dickinson

messages: + msg106956
resolution: fixed -> (no value)
stage: patch review -> needs patch

versions: + Python 2.6, Python 3.0, Python 3.1, Python 2.7
keywords: + patch, easy
nosy: + r.david.murray

messages: + msg84362
stage: patch review