[Python-Dev] Broken strptime in Python 2.3a1 & CVS

Tim Peters tim.one@comcast.net
Mon, 13 Jan 2003 15:51:51 -0500


[Kevin Jacobs]
> I depend on the default version that is exposed via the time module when
> using Python 2.2 under Solaris 9.

Let's hope that means something to Brett <wink>.

> This is the only one that has emerged from a real-life running
> application.  In fact, this kind of code is our only use of strptime,
> though after all of this confusion it may be replaced RSN with
> something more deterministic.

Possibly wise.  I'm not sure why ANSI C refused to adopt strptime(), but
suspect it's because it was such a legacy mess.

> I'm not sure what else you expect of me.

To make it your full-time job to specify behavior in all cases, of course.

> I have an application, some anecdotal evidence that something is amiss,
> reported specific test-code that that demonstrated problem, and encouraged
> Brett do a bit of digging though the standards to see if he can improve
> things.

That's helpful itself, and appreciated.  It turns out the standards aren't
helpful, though.

> If you feel that I am being unreasonably vague about what Brett should do,
> then you are quite right!  I'm burried under a dozen other projects, and
in
> spite of that, felt it was important to make time to test Python 2.3a1.

That's good.  Thank you.

> In doing so I found one concrete thing wrong with how we used strptime and
> a bucket full of things that looked fishy.  However, digging through the
> nooks and crannies of strptime is not at all important to me, especially
> when I have a viable work-around on all platforms that I care about (i.e.,
> re-enabling the libc version).
>
> Happy to help, but not expecting the Spanish Inquisition,

I was trying to provoke you into being specific, on the chance that you did
know exactly what you wanted but felt it was "too obvious" to bother
spelling it out.  My apologies if that came across as offensive or too
strong.  Getting concrete use cases remains the most helpful thing that can
be done, whether or not a standard backs them.  Python inherited a lot of
platform accidents from platfrom strptime() implementations (and, indeed,
the Python docs warned about that all along), and we simply can't know which
accidents were important to people if they don't complain now.  We can do
something "reasonable" if we know what they are, but nobody knows what all
the platform accidents were, so "backward compatible in all cases" is an
unachievable wish.