[Python-Dev] Add UTC to 2.7 (PyCon sprint idea)

[Stuart Bishop]

On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" <martin at 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 <stuart at stuartbishop.net>
http://www.stuartbishop.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100219/234f3d95/attachment-0001.pgp>