[Python-Dev] Draft PEP for time zone support.
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:
> 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 :``get_timezone(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
> 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 is_dst. When ``is_dst`` is
> implemented directly in ``datetime.tzinfo`` they are no longer needed.
> * The ``pytz`` method ``timezone()`` is instead called
> ``get_timezone()`` for clarity.
> * ``get_timezone()`` will return the local time zone if called
> without parameters.
> * The class ``pytz.StaticTzInfo`` is there to provide the ``is_dst``
> support for static
> timezones. When ``is_dst`` 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.
> 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,
Looking forward to have timezone support in the stdlib!
More information about the Python-Dev