[Python-Dev] tzset (original) (raw)

Tim Peters tim.one@comcast.net
Sun, 16 Mar 2003 00:07:47 -0500

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