[Python-Dev] Broken strptime in Python 2.3a1 & CVS
Kevin Jacobs
jacobs@penguin.theopalgroup.com
Mon, 13 Jan 2003 06:38:57 -0500 (EST)
On Sun, 12 Jan 2003, Tim Peters wrote:
> > But otherwise I am fine with it defaulting to 1900-01-00 as Kevin seems
> > to be suggesting.
>
> It's hard to know what Kevin was suggesting -- he was mostly appealing to
> emperors that turn out to have no clothes <wink>.
;)
I was appealing to the Linux, Tru64Unix, IRIX, and Solaris emperors, all
naked, then.
> > and then calculate the Julian day and day of the week? That way the
> > default values will be valid *and* not mess up ``time.mktime()``?
>
> Kevin is the only one with a real use case here so far, and he needs to
> define what he wants with more rigor. It may or may not turn out to be
> feasible to implement that, whatever it is.
My first e-mail did just that. I want
def round_trip(n):
strftime('%m/%d/%Y', localtime(mktime(strptime(n, '%m/%d/%Y')))
assert n == round_trip(n)
when n is a valid date value. This is my major use-case, since the lack of
being able to round-trip date values breaks all of our financial tracking
applications in _very_ ugly ways.
i.e., with libc strptime:
round_trip('07/01/2002') == '07/01/2002'
with Brett's strptime:
round_trip('07/01/2002') == '06/30/2002'
Along the way, I pointed out several other places where Brett's strptime
departed from what I was used to, with the hope that those issues could be
examined as well.
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com