On Mon, Oct 1, 2012 at 5:25 PM, Barry Warsaw <ba...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
