[Python-Dev] Draft PEP for time zone support. (original) (raw)

Lennart Regebro regebro at gmail.com
Wed Dec 12 16:56:54 CET 2012

General comments:

It seems like the consensus is moving towards making sure there always is a database available. If this means including it in the standard Python distribution as well, or only on Windows, I don't know, opinions on that are welcome.

The steps to look for a database would then change to:

  1. The path specified, if not None.

  2. The module for timezone "overrides".

  3. The OS database.

  4. The database included in Python.

We need to determine if a warning should be raised in case of 4 or not, as well as the name for the override module. I think the word "override" here is possibly unclear, I'd prefer something like "timezone-update" or similar.

I'm personally a bit sceptical to writing a special updater/installer just for this. I don't want to have a special unique way to install this package.

As it comes to OS packages, Christian Heimes pointed out that most Windows installations today has Java installed, and kept updated, and it has a zoneinfo database. We could consider using that on Windows as well, although it admittedly feels quite icky.

I haven't been able to find any other common locations for the zoneinfo database on Windows.

Specific answers:

On Tue, Dec 11, 2012 at 4:39 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

I wonder if there needs to be something here about how to port from pytz to the new timezone library.

It would be nice to have, but I don't think it's necessary to have in the PEP.

It seems like calling gettimezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception?

That could very well be. What are others opinions on this?

Why not keep a bit more of the pytz API to make porting easy?

The renaming of the timezone() function to get_timezone() is indeed small, but changing pytz.timezone(foo) to timezone.timezone(foo) is really significantly easier than renaming it to timezone.get_timezone(foo).

If we keep all of the API intact you could do

try:
    import pytz as timezone
except ImportError:
    import timezone

Which would make porting quicker, that's true, but do we really want to keep unecessary API's around forever? Isn't it better to minimize the noise from the start?

It also seems relatively painless to keep localize() and normalize() functions around for easy porting.

Sure, but you then have two ways of doing the same thing, which I think we should avoid.

On Tue, Dec 11, 2012 at 5:07 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

The isdst parameter can be True (default), False, or None.

Why is it True by default? Do we have statistics showing that Python gets more use in summer?

Because for some reason both me and Stuart Bishop thought it should be, but at least in my case I don't have any actual good reason why. Checking with how pytz does this shows that pytz in fact defaults to False, so I think the default should be False.

On Wed, Dec 12, 2012 at 3:50 AM, Barry Warsaw <barry at python.org> wrote:

This is likely the hardest part of this PEP as this involves updating the

Oops, something got cut off there.

Ah, yes, I was going to write that the difficult bit was updating the _datetime.c module.

Why add a new module instead of putting all this into the existing datetime module, either directly or as a submodule? Seems like the obvious place to put it instead of claiming another top-level module name.

pytz as it is consists of several modules, and a significant amount of code, it didn't feel right to move all that into the datetime.py module. It also didn't feel right to then not implement it in _datetime.c, but perhaps that's just me being silly.

But a submodule could work.

I'm bikeshedding, but can we find a better name than db for the second argument? Something that makes it obvious we're looking for file system path?

Absolutely. db_path?

I'd really like to see a TimeZoneError base class from which all these new exceptions inherit.

That makes sense.

The timezonedata-package ----------------------------- Just to be clear, this doesn't expose any new modules, right?

That's the intention, yes, although I haven't investigated ways of knowing if it's installed or not yet, and exposing a module is the obvious way of doing that. But I'm hoping there will be better ways, right?

One other thing that the PEP should describe is what happens on a distro that has timezone data, but which you also pip install the PyPI tzdata package. Which one wins? Is there a way to control it, other than providing an explicit path? Is there a way to uninstall the PyPI package? Does the API need to provide a method which tells you where the database it is using by default lives?

The PyPI package wins, I'll clarify that bit. I'm think the data should end up in site-packages somewhere, and that it should be installable and uninstallable with pip/easy_install and by simply deleting it.

On Wed, Dec 12, 2012 at 4:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

That's a backwards compatibility risk, though - many applications are likely coping just fine with the slightly corrupted time values, but would fall over if an exception was raised instead. The default should probably be chosen so that the single argument form of these calls continues to behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to say that the default behaviour is going to change in 3.5 (so the actual default would be sentinel value, in order to tell the difference between an explicit True being passed and relying on the default behaviour).

Although explicit is better than implicit, I think this is one case where this doesn't apply. The cases where you really care which half past two you meant, or the cases where you want an error when you specify 2012-03-25 02:30 in Europe/Stockholm is exceedingly rare. Most people would not know this can happen, and therefore they would not handle the errors, but they would not want the application to fail when it does happen. I think the default therefore should be True or False.

More information about the Python-Dev mailing list