[Python-Dev] Stdlib and timezones, again (original) (raw)

Lennart Regebro regebro at gmail.com
Mon Oct 1 17:29:11 CEST 2012

On Mon, Oct 1, 2012 at 5:25 PM, Barry Warsaw <barry at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20121001/5bd7516b/attachment.html>

More information about the Python-Dev mailing list