On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro <rege...@gmail.com> wrote:
> Abstract > ======== > > This PEP proposes the implementation of concrete time zone support in the > Python standard library, and also improvements to the time zone API to deal > with ambiguous time specifications during DST changes. > Thanks for tackling this one, Lennart. > Proposal > ======== > > Concrete time zone support > -------------------------- > > The time zone support in Python has no concrete implementation in the > standard library, only a tzinfo baseclass, and since Python 3.2, one > concrete > time zone: UTC. This isn't quite right - the current concrete timezones support any fixed offset from UTC, not just UTC itself. http://docs.python.org/3/library/datetime#timezone-objects (Although there a couple of bugs in those docs at the moment: http://bugs.python.org/issue16667) > The time zone support will be implemented by a new module called > `timezone``, > based on Stuart Bishop's ``pytz`` module. > Ick, why a new module? Why not just add this directly to datetime? (It doesn't need to be provided by the C accelerator, it can go straight in the pure Python part). > 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 > Missing the end of this sentence... > The ``timezonedata``-package > ----------------------------- > > The zoneinfo database will be packaged for easy installation with > ``easy_install``/``pip``/``buildout``. This package will not install any > Python code, and will not contain any Python code except that which is > needed > for installation. > I'd prefer a more aggressive name for this like "tzdata_override". My rationale is that *nix users need to thoroughly aware that if they install this package, they will stop benefiting from the automatic tz database updates provided by their OS (especially if they install it into the system site packages on a distro that has migrated to Python 3 for system tools). Such a name would also make it possible to provide *two* packaged databases, one checked before the OS data (tzdata_override), and one shipped with Python itself that is used only if the OS doesn't provide the timezone database (tzdata_fallback). tzdata_fallback would then be updated to the latest Olsen database for each maintenance release. Cross-platform applications that wanted more reliably up to date timezone data could then conditionally depend on tzdata_override for Windows deployments (using the environment marker support in metadata 1.2+). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ 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
