[Python-Dev] tzset

[Tim Peters]

[Brett Cannon]
> 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
    implementation-defined manner.

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

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.