But is the "You don't have to install it" really such a big problem so that it's worth the other problems like platform incompatibilities and such?
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. :) On Fri, Feb 19, 2010 at 05:59, Stuart Bishop <stu...@stuartbishop.net> wrote: > On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro <rege...@gmail.com> wrote: >> >> On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" <mar...@v.loewis.de> >> wrote: >>> >>> That's not true. The registry is readable by any user, and the format is >>> fully documented. >> >> Yes, but they use non-standard locations, and afaik, pytz does not >> support it. If a stdlib pytz would use this you would have to use >> different timezone names for Unix and Windows. I don't think that's a >> good idea. > > Under Windows the only backend API I'm aware of we could use is tzwin and I > think any standard library inclusion would require this or something > similar. For the standard library, I think it would be great if you could do > 'datetime.timezone(some_string)' and get a tzinfo instance suitable for most > use cases which seems no problem for tzwin to provide (platform default DST > information, simple interface with potentially incorrect localized datetime > arithmetic over DST transitions). It is unfortunate that the timezone > strings are platform specific, but I feel that is still better than end > users having to keep updating timezone databases or not supporting > non-zoneinfo systems at all. Even with pytz, the timezone strings are > version specific to an extent (we had a real issue where we updated pytz on > our web applications, which changed a preferred timezone name from > Asia/Calcutta to Asia/Kolkata per requests from our users and as a result > our wiki's exploded for some users as they where on separate boxes using a > different pytz release that didn't understand that timezone string). > > It would also be trivial to always look up timezone information from > compiled zoneinfo files in a well known location if the system timezone > database cannot find the requested timezone information. So > datetime.timezone('US/Eastern') would work on Windows if you had installed > pytz (I'd update pytz to install its zoneinfo files into the blessed > location). Best of both worlds. > >> Also, the windows data contains only current timezone data, so for >> calendars stretching back in time, the Olsen database would be >> preferable as it keeps history. > > Sure. I'm not saying pytz will disappear or become unmaintained for people > who need it. I believe most people who are using it now don't need it and > I'm sure there are real bugs in real code out there because of this, as > using pytz correctly requires reading and understanding the pytz > documentation. > > > If this is all too ambitious, tzinfo implementations in the standard library > for UTC and the current system timezone would be a step forward and solve > most real world use cases. > > -- > Stuart Bishop <stu...@stuartbishop.net> > http://www.stuartbishop.net/ > > -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com