[ 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: 7
Submitted By: Jp Calderone (kuran)
Assigned to: Barry A. Warsaw (bwarsaw)
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-26 17:53

Message:
Logged In: YES 
user_id=357491

=)  No need to presume; I know better.

Writing strftime in Python would be rather difficult since there is no other 
consistent way to get at all of that locale info.  Yes, you could use the 
locale module, but even that is iffy at times on some platforms.

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

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 08:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

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

Comment By: Jp Calderone (kuran)
Date: 2004-07-25 22:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


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

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 21: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 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