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

[Lennart Regebro]

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 <stuart at stuartbishop.net> wrote:
> 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/
>
>
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64