New submission from Gregory P. Smith:
Some common python utilities had problems on Feb 29 this year when
parsing dates using format strings that did not include a year in them.
>>> time.strptime('Feb 29', '%b %d')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/_strptime.py", line 425, in strptime
julian = datetime_date(year, month, day).toordinal() - \
ValueError: day is out of range for month
This is apparently because python assumes the year is 1900 unless it
explicitly parses another year out of the string.
Applications can work around this by always adding a year and a %Y to
the string they are parsing.
But not all date manipulating applications care about years. In this
case the application was fail2ban, bug report and patches to it here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382
Should the year default to 1900 (the equivalent of what the much more
forgiving C API does by leaving struct tm tm_year = 0) or should this
error be raised? If the answer is yes, works as is this is easy and
just turns into us adding a note in the documentation to mention the
behavior.
I do believe this was a valid bug in fail2ban as assuming the current
year for date parsing is a bad idea and will do the wrong thing when
parsing across a year change.
Python's strptime is much more strict than C strptime (glibc's C
strptime is happy to return tm_mon 2 tm_mday 31. Its range checking is
minimal.
here's a C test case to play with its behavior:
#include <assert.h>
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[]) {
unsigned long ret, parsed;
assert(argc == 2);
struct tm tm = { 0 };
ret = strptime(argv[1], "%b %d", &tm);
parsed = ret - (unsigned long)(argv[1]);
printf("ret 0x%x parsed %d tm_mon %d tm_mday %d tm_year %d\n",
ret, parsed,
tm.tm_mon, tm.tm_mday, tm.tm_year);
}
% ./foo 'Feb 28'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 28 tm_year 0
% ./foo 'Feb 29'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 29 tm_year 0
% ./foo 'Feb 31'
ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 31 tm_year 0
% ./foo 'Feb 32'
ret 0x0 parsed 9596 tm_mon 1 tm_mday 0 tm_year 0
----------
components: Library (Lib)
keywords: easy
messages: 63236
nosy: gregory.p.smith
priority: low
severity: minor
status: open
title: time.strptime too strict? should it assume current year?
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2227>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
