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) 

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.

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.

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?

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

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.

Logged In: YES 
user_id=764593

What about a python wrapper to the C function that accepted 
either short tuples or None in trailing (or any?) positions and 
automatically filled in a default value.

Some can be computed from other fields; if not, the same 
defaults used in strptime seem as reasonable as any.

Logged In: YES 
user_id=357491

I could live with the None option but not the short tuple option.  The 
former is explicitly not a number and nothing returns that for time tuples 
to my knowledge.  The latter, though, might mask bugs in code when you 
accidentally truncated your tuple too much.

And yes, other values can be computed from other fields (strptime has 
the code for some slots and I think datetime can do some as well).  But 
why waste the overhead?  While strptime has to care since you are 
getting a time tuple and thus it can't guess what fields you care about, 
strftime shouldn't need to care since it is assumed that you are passing 
in as much info as needed for the format directive to have what it needs.

Logged In: YES 
user_id=764593

For me, Day-of-week and day-of-year are typically there 
because the format was decided externally; I don't track them 
in my application.

I've seen databases with timestamps that all end in "000".

I would be happy to have "None" replaced by a default value; 
it is just that the result should be consistent with what I did 
pass.  For example, I wouldn't want to pass year/month/day 
and discover that every single day is Monday, or to pass year/
day-of-year and discover that day 345 is still in January.

-jJ

Logged In: YES 
user_id=366566

Diff to update _parseaddr and rfc822 modules to use 0
instead of 1 for values it does not compute.  Test module
also updated (it explicitly compared to 0, now it explicitly
compares to 1).

Logged In: YES 
user_id=366566

0s and 1s reversed in previous post.  Correct in patch, though.

Logged In: YES 
user_id=12800

The patch isn't quite right, since 0 is only illegal in the
yday position - the wday and isdst positions should continue
to return 0.  Also, your patch didn't include a fix to
test_rfc822.py

But I'll fix those and commit the changes.