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 >involves updating >the 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 > `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``. 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 exceptions inherit. >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. >* ``AmbiguousTimeError`` > >* ``NonExistentTimeError`` 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. > >The ``timezonedata``-package >----------------------------- Just to be clear, this doesn't expose any new modules, right? Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
