This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, datacompboy, georg.brandl, mark.dickinson, r.david.murray
Date 2010-06-03.14:46:48
SpamBayes Score 2.3010516e-05
Marked as misclassified No
Message-id <1275576411.02.0.710358184752.issue2568@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-06-03 14:46:51belopolskysetrecipients: + belopolsky, georg.brandl, mark.dickinson, datacompboy, r.david.murray
2010-06-03 14:46:51belopolskysetmessageid: <1275576411.02.0.710358184752.issue2568@psf.upfronthosting.co.za>
2010-06-03 14:46:49belopolskylinkissue2568 messages
2010-06-03 14:46:48belopolskycreate