[Python-Dev] datetime module and pytz with dateutil

[Nick Coghlan]

On Fri, Mar 30, 2012 at 10:47 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Fri, 30 Mar 2012 13:38:13 +0300, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> 28.03.12 23:20, Andrew Svetlov написав(ла):
>> > I figured out what pytz and dateutil are not mentioned in python docs
>> > for datetime module.
>> > It's clean why these libs is not a part of Python Libraries — but
>> > that's not clean for Docs.
>>
>> I don't understand why Python may not include the pytz. The Olson tz
>> database is not part of pytz. Python can depend on a system tz database,
>> as it depends on libssl or libbz2, which also can be updated (for
>> security reasons) independently.
>
> There is an extensive discussion of this somewhere in the archives of
> this list.  If I remember correctly, it boils down to the fact that pytz
> does bundle the database, and that Windows either does not have or does
> not regularly update its own Olson database.  Rather than ship something
> out-of-date, we choose to put the onus on the user to ensure that the
> appropriate code+db exists on their system.
>
> Hopefully someone will correct me if I'm wrong, and/or find a pointer
> to the relevant thread.

That's my recollection as well. Because we don't want to take on the
task of providely timely updates in response to timezone database
changes, any named timezone support added to the stdlib would need to
be based on a system provided timezone database, rather than the
bundled database model used by pytz. This is straightforward on *nix
based systems that provide the zoneinfo structure in the filesystem,
but more complicated on Windows (which has its own custom scheme).

Before the idea of adding full timezone support to the standard
library could be seriously considered someone would have to, at the
very least, use the mapping data from the Unicode Consortium's CLDR
Supplementary data to map the standard Olsen database timezone names
to the correct values to look up through the Windows timezone APIs
(http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html)

Adding mappings for *new* timezones would still be controlled by our
release cycle (although I think it would be reasonable to permit such
additions in maintenance releases), but updates in response to things
like daylight savings dates changing would then be the responsibility
of the OS vendors. However, "pip install pytz" is easy enough that
there isn't a lot of motivation for anyone to do the work to switch
from a bundled copy of the timezone database to a bundled TZID ->
Windows API lookup mapping.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia