[ python-Bugs-997368 ] strftime() backwards incompatibility

[SourceForge.net]

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470