On Mon, Oct 1, 2012 at 5:25 PM, Barry Warsaw <barry@python.org> wrote:
On Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote:

>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.

Why include the database in Python at all?

Exactly my point.
 
If you have an OS that keeps the system tz data up-to-date, I can't think of
any reason why you wouldn't want to use it.

If you don't have the data, why not include information in the documentation
for how to download and install the database in a location that Python will
search for, along with information on how to enable that?  You could even
provide a nice script that would download, install, and optionally enable that
tz data's use.

Right, I was going to do that by bundling the files in a package, tentatively called pytzdata, available on PyPI, so it can be easy_installed/pip installed, etc.
 
I think that would cover all the bases:

* My OS keeps the tz data up-to-date.  I don't have to do nuthin', and Python
  gives me a nice API for using all the world's timezones on my superb OS.

* My OS keeps the tz data up-to-date, but I'm skeptical.  I run the update
  script whenever is appropriate, adding the --enable flag, and the tz data is
  grabbed from the intarwebs, installed, and Python starts using it instead of
  the system data.

* I am sad because I use an OS that has no tz data.  I run the update script
  once in a while, adding the --enable flag, and my Python is timezonally
  happy.

* I'm sad and lazy.  Oh well, Python throws an exception when I try to use a
  timezone that isn't UTC.

We seem to be on the same page here.

//Lennart