On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro <rege...@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 _______________________________________________ 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
