[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed in revision 87910.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

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 .

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

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

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.

--
assignee:  -> belopolsky
nosy: +mark.dickinson
resolution: fixed -> 
stage: patch review -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[R. David Murray]

R. David Murray  added the comment:

Doc patch applied in r71037.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[R. David Murray]

R. David Murray  added the comment:

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.

--
keywords: +easy, patch
nosy: +bitdancer
priority:  -> low
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13451/issue2568-doc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> 

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Okay, sorry that I made uninformed guesses :)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Wed, Apr 9, 2008 at 2:49 PM, Georg Brandl <[EMAIL PROTECTED]> 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 "", line 1, in 
ValueError: second must be in 0..59

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

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

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

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Mon, Apr 7, 2008 at 3:42 PM, Anton Fedorov <[EMAIL PROTECTED]> 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

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Anton Fedorov]

Anton Fedorov <[EMAIL PROTECTED]> added the comment:

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 "", line 1, in 
ValueError: second must be in 0..59

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

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.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

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 "", line 1, in 
ValueError: second must be in 0..59
>>> datetime.strptime('2101T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: second must be in 0..59

--
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +belopolsky, georg.brandl

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2568] Seconds range in time unit

[Anton Fedorov]

New submission from Anton Fedorov <[EMAIL PROTECTED]>:

"%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.

--
components: Library (Lib)
messages: 65067
nosy: datacompboy
severity: normal
status: open
title: Seconds range in time unit
type: behavior

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com