Stuart Bishop wrote: > On Sunday, March 16, 2003, at 04:07 PM, Tim Peters wrote: > >> 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. > > 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. >> 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. > > 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. -1 Why bloat the Python distribution with yet another locale implementation ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 15 days left EuroPython 2003, Charleroi, Belgium: 99 days left
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