Sun, 16 Mar 2003 00:07:47 -0500
> If there is one thing I have learned from writing _strptime is that you
> cannot be strict in the slightest for your input when it comes to
> time-based data. I think this is another case where you need to be loose
> about input and strict with output.
Python doesn't do anything with TZ's value -- it doesn't even look to see
whether TZ is set, let alone parse it (well, Python's obsolete tzparse
module parses TZ's value, but the new code in question does not).
The cross-platform semantics of TZ are a joke. The tests we have rely on
non-standard extensions (viewing POSIX as the only definitive std here).
Even if they stuffed colons at the front, POSIX leaves the interpretation of
colon-initiated TZ values entirely up to the implementation:
If TZ is of the first format (that is, if the first character is a
colon), the characters following the colon are handled in an
Worse, if the platform tzset() isn't happy with TZ's value, it has no way to
tell you: the function is declared void, and has no defined effects on
I hope the community takes up the challenge of building a sane
cross-platform time zone facility building on 2.3 datetime's tzinfo objects.