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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
