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

[Tim Peters]

[Kevin Jacobs]
> I was appealing to the Linux, Tru64Unix, IRIX, and Solaris emperors, all
> naked, then.

That's not a spec, it's just a collection of OS names, and, for the most
part, their man pages are even vaguer than the POSIX partial spec.  The IRIX
collection is especially funny <wink>:

          o Bug #469938 - strptime() does not parse %y formats
            correctly.

          o Bug #469941 - strptime() does not give correct return
            value.

          o Bug #515837 - strptime() %y does not handle years 2000
            and greater.

The Solaris docs are the only ones that show any awareness that there *are*
unclear behaviors here, and they don't promise anything across releases
despite that:

    In addition to the behavior described above by various standards, the
    Solaris implementation of strptime() provides the following extensions.
    These may change at any time in the future. Portable applications should
    not depend on these extended features:

    If _STRPTIME_DONTZERO is not defined, the tm struct is zeroed on entry
    and strptime() updates the fields of the tm struct associated with the
    specifiers in the format string.  [Note from Tim:  I believe this
    violates the POSIX spec, although the latter is too vague to say for
    sure.]

    If _STRPTIME_DONTZERO is defined, strptime() does not zero the tm struct
    on entry.  Additionally, for some specifiers, strptime() will use some
    values in the input tm struct to recalculate the date and re-assign the
    appropriate members of the tm struct.

    [yadda yadda yadda]

So which version of which Solaris variation do you depend on?

> 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,

If you have other use cases, do spell them out.  I expect this specific use
case will prove to be tractable.

> 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.

They've been examined, but the specs don't say enough to resolve anything.
Poke and hope appears all that remains.  Specific use cases may help, but
more OS names won't.