[Python-Dev] Stdlib and timezones, again (original) (raw)
Barry Warsaw barry at python.org
Mon Oct 1 17:25:08 CEST 2012
- Previous message: [Python-Dev] Stdlib and timezones, again
- Next message: [Python-Dev] Stdlib and timezones, again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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?
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.
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.
Cheers, -Barry
- Previous message: [Python-Dev] Stdlib and timezones, again
- Next message: [Python-Dev] Stdlib and timezones, again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]