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

Dirkjan Ochtman dirkjan at ochtman.nl
Tue Dec 11 16:39:33 CET 2012

On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro <regebro at gmail.com> wrote:

Proposal ========

The time zone support will be implemented by a new module called `timezone,_ _based on Stuart Bishop's pytz`` module.

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

* New function :gettimezone(name=None, db=None)

This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". If not given, the local timezone will be looked up. If an invalid zone name are given, or the local timezone can not be retrieved, the function raises UnknownTimeZoneError. The function also takes an optional path to the location of the zoneinfo database which should be used. If not specified, the function will check if the timezonedata module is installed, and then use that location or otherwise use the database in /usr/share/zoneinfo. If no database is found an UnknownTimeZoneError or subclass thereof will be raised with a message explaining that no zoneinfo database can be found, but that you can install one with the timezonedata package.

It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception? It would probably be a good idea to have a different exception for the case of no database available.

Differences from the pytz API =================================

* pytz has the functions localize() and normalize() to work around that tzinfo doesn't have isdst. When isdst is implemented directly in datetime.tzinfo they are no longer needed. * The pytz method timezone() is instead called gettimezone() for clarity. * gettimezone() will return the local time zone if called without parameters. * The class pytz.StaticTzInfo is there to provide the isdst support for static timezones. When isdst support is included in datetime.tzinfo it is no longer needed.

This feels a bit superfluous. Why not keep a bit more of the pytz API to make porting easy? The pytz API has proven itself in the wild, so I don't see much point in renaming "for clarity". It also seems relatively painless to keep localize() and normalize() functions around for easy porting.

Discussion ==========

Should the windows installer include the data package? ------------------------------------------------------ It has been suggested that the Windows installer should include the data package. This would mean that an explicit installation no longer would be needed on Windows. On the other hand, that would mean that many using Windows would not be aware that the database quickly becomes outdated and would not keep it updated.

I still submit that it's pretty much just as easy to forget to update the database whether it's been installed by hand zero or one times, so I don't find your argument convincing. I don't mind the result much, though.

Looking forward to have timezone support in the stdlib!

Cheers,

Dirkjan

More information about the Python-Dev mailing list