Mon, 17 Mar 2003 16:26:08 -0500
>> Yup. It sucks, but is the best there is. I can't even find proprietary
>> solutions for various Unix flavours. Maybe a post to Slashdot saying
>> Zope 3 will be Windows only due to limitations in POSIX would at least
>> get something for the free distros :-)
> I wonder why we need a TZ-parser then ? If it's non-standard
> anyway, the module is probably better off outside the core as
> separate download from e.g. SF.
TZ parsing code hasn't been added to Python, just a wrapper around the
platform tzset() function (if any, and for now ignoring the flavor of tzset
supplied by Windows). POSIX defines various forms TZ values can take. Some
forms have portable meaning across POSIX systems, while others do not.
>>> I hope the community takes up the challenge of building a sane
>>> cross-platform time zone facility building on 2.3 datetime's tzinfo
>> A cross-platform time zone facility isn't a problem - the data
>> we need is available and maintained as part of numerous free Unix
>> distributions. We could even steal C code to decode it if we are
>> particularly lazy.
> Why bloat the Python distribution with yet another locale
> implementation ?
Well, I didn't say anything about the std distribution. Whether there or
elsewhere, Python didn't and doesn't have any portable (x-platform) way to
deal with time zones. 2.3's tzinfo objects are capable of carrying time
zone information in a sane x-platform way, but no concrete tzinfo objects