| msg21799 - (view) |
Author: Jean-Paul Calderone (exarkun) *  |
Date: 2004-07-25 03:59 |
| 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) |
|
|
| msg21800 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2004-07-26 02:39 |
| 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. |
|
|
| msg21801 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2004-07-26 04:45 |
| 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. |
|
|
| msg21802 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2004-07-26 05:25 |
| 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? |
|
|
| msg21803 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2004-07-26 15:30 |
| 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 . |
|
|
| msg21804 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2004-07-27 00:53 |
| 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. |
|
|
| msg21805 - (view) |
Author: Jim Jewett (jimjjewett) |
Date: 2004-07-27 15:01 |
| 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. |
|
|
| msg21806 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2004-07-27 22:41 |
| 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. |
|
|
| msg21807 - (view) |
Author: Jim Jewett (jimjjewett) |
Date: 2004-07-27 22:58 |
| 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 |
|
|
| msg21808 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2004-08-05 16:10 |
| 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). |
|
|
| msg21809 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2004-08-06 21:03 |
| Logged In: YES user_id=366566 0s and 1s reversed in previous post. Correct in patch, though. |
|
|
| msg21810 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2004-08-07 16:38 |
| 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. |
|
|