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

[SourceForge.net]

Bugs item #997368, was opened at 2004-07-24 20:59
Message generated for change (Comment added) made by bcannon
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: Brett Cannon (bcannon)
Date: 2004-07-25 19: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