[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