[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4