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

Nick Coghlan ncoghlan at gmail.com
Wed Dec 12 01:58:12 CET 2012

On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro <regebro at 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.

(Although there a couple of bugs in those docs at the moment:

> 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+).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121212/a97447a5/attachment.html>

More information about the Python-Dev mailing list