[Python-Dev] Draft PEP for time zone support. (original) (raw)

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. 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 isdst 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 easyinstall/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 | 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