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

[Stuart Bishop]

On Tue, Feb 16, 2010 at 11:18 PM, Tres Seaver <tseaver at palladion.com> wrote:

> Dirkjan Ochtman wrote:
>> On Tue, Feb 16, 2010 at 16:26, Tres Seaver <tseaver at palladion.com> wrote:
>>> Because timezones are defined politically, they change frequently.  pytz
>>> is released frequently (multiple times per year) to accomodate those
>>> changes:  I can't see any way to preserve that flexibility if the
>>> package were part of stdlib.
>>
>> By using what the OS provides. At least on Linux, the basic timezone
>> data is usually updated by other means (at least on the distro I'm
>> familiar with, it's updated quite often, too; through the package
>> manager). I'm assuming Windows and OS X would also be able to provide
>> something like this. I think pytz already looks at this data if it's
>> available (precisely because it might well be newer).
>
> If that were so, I don't think Stuart would be going to the trouble to
> re-release the library 6 - 12 times per year.

The Debian, Ubuntu and I think Redhat packages all use the system
zoneinfo database - there are hooks in there to support package
maintainers that want to do this. This way the package can be included
in the supported release but still receive timezone information
updates via the OS (but no code updates, but these are rare and
usually irrelevant unless you where the person who filed the bug ;) ).

I'd be happy to rework pytz for the standard Library using the system
installed zoneinfo database if it is available. I think for the
standard library though, it needs to follow the documented API better
rather than the .normalize() & .localize rubbish I needed to get
localized datetime arithmetic working correctly. Having seen the
confusion and bug reports over the last few years, I think people who
need this are in the minority and pytz can still exist as a separate
package to support them. tzwin could be used on Windows platforms -
I'd need to look into that further to see if the API can remain
consistent between *nix and Windows. I suspect that pytz without the
.normalize() & .localize() rubbish may look remarkably similar to
dateutil so that might be a better option to start from.

We could consider extending the existing datetime library to support
localized datetime arithmetic. This would either involve adding an
extra bit to datetime instances to support the is_dst flag (originally
deemed unacceptable as it increased the pickle size by a whole byte),
or better support for tzinfo implementations to store the is_dst flag
in the tzinfo instance (the approach pytz used). This requires a C
programmer though and I'm so very, very rusty.

I am not at pycon alas. Some of my coworkers from Canonical will be
though and they might be interested as we use pytz for Launchpad and
other Canonical projects.

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/