[Python-Dev] Stdlib and timezones, again

[Lennart Regebro]

With 3.3 out, it's time to bring up something for 3.4. And it's about pytz
and stdlib, basically. And we have been over that again, but I have a
proposal anyway.

The problem with including pytz in the stdlib is that it contains the
tz/zoneinfo/Olson database, and it updates much more often than Python
does. I propose to solve this problem in the following way:

1. Merge the functionality of pytz into the stdlib datetime module. That
means extending datetime.tzinfo with the localize() function and and adding
a top-level datetime.timezone() function. any other extra functionality
pytz has.

2. The datetime.timezone() function will work as the pytz.timezone()
function, ie return a tzinfo object from the tz database.

3. However, Python will not include the database. Instead it will use the
one that the OS provides, if it provides one (ie Unices, including OS X if
I remember correctly).

4. On any other OS, datetime.timezone() will return an error explaining
that no tz database can be found, but that it is available in the module
'pytzdata' which then will need to be created. If this module is installed,
the datetime.timezone() function will prefer that database before the OS
database.

5. We can also consider implementing something like the get_localzone()
function of my module tzlocal.

This solves two problems.

i. We have real, useful timezone support in Python. For Unix, it's
included, for all other systems, it's just an extra module. The extra
module can also be installed to give Python up to date tz information even
when the operating system is outdated and unsupported and no
longer receiving updates.

ii. pytz is_dst flag becomes included in stdlib, solving one of the few
imperfections in the current library.

What do you say? Is this a path worth pursuing?

//Lennart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120930/1216ad01/attachment.html>