On Fri, Feb 19, 2010 at 07:27, Stuart Bishop <stuart at stuartbishop.net> wrote: >> In any case, since you want to make a version that can be included and >> uses the timezone API, I guess that's a moot question until we have >> that version. :) > > As I understand it dateutil pretty much already provides what I'm describing. Well, pretty much yes. I don't know how good it is at using the system data without an Olsen database, but it shouldn't be too much work to add that, I guess. But that changes the topic from moving pytz to stdlib into moving dateutil.tz into stdlib. :) Personally I like pytz "anal" timezone support though, and dateutil.tz doesn't have that, and I still think it would be possible to have both in one system, but using different API-calls. Also, people have uttered negativities about datetime.tz, but they have never been able to say what they don't like about it. I would like if we could look into making a timezone module that works on Python 2.5 to 3.2 that uses system data, unless there is also a "Olsen module" installed, and that has all the features of both dateutil.tz and pytz, ie: 1. Support for the standard API. 2. A Pytz extended API. 3. Using the system data. 4. Using a separate Olsen database installable by normal Python means. 5. Perhaps a timezone name alias map? That could map both old Olsen names and Windows names. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
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