[Python-Dev] Draft PEP for time zone support.
barry at python.org
Wed Dec 12 03:50:49 CET 2012
Great work, Lennart. I really like this PEP. Feedback follows (I haven't yet
read the rest of the messages in this thread ;).
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
>This PEP proposes to add these ``is_dst`` parameters to the relevant methods
>of the ``datetime`` API, and therefore add this functionality directly to
>``datetime``. This is likely the hardest part of this PEP as this
Oops, something got cut off there.
>The new ``timezone``-module
>The public API of the new ``timezone``-module contains one new class, one new
>function and one new exception.
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.
>* New class: ``DstTzInfo``
> This class provides a concrete implementation of the ``zoneinfo`` base
> class that implements DST support.
Is this a subclass of datetime.tzinfo?
>* 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``.
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?
>* New Exception: ``UnknownTimeZoneError``
I'd really like to see a TimeZoneError base class from which all these new
>A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
>handle time ambiguity during DST changeovers.
>* ``tzinfo.utcoffset(self, dt, is_dst=True)``
I lied a little bit - I did skim the other messages, so I'll reserve comment
on the default value of is_dst for follow ups.
I'm not positive we need separate exceptions here, but I guess it can't hurt,
and with the base class idea above, we can catch both either explicitly, or by
catching the base class.
Just to be clear, this doesn't expose any new modules, right?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev