[Python-Dev] Draft PEP for time zone support.

[Dirkjan Ochtman]

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 :``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
>   `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 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.

> 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