[Python-Dev] Stdlib and timezones, again

[Nick Coghlan]

On Mon, Oct 1, 2012 at 5:23 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Python 2.3 has been EOL'ed for years. It definitely is not up-to-date,
> for any reasonable definition of the term. For example, it will have
> many unplugged security holes. So will that user's version of OpenSSL
> and other libraries. If they don't want to apply security fixes, why
> should we even care about their timezones' freshness?

Exactly. If a service provider has a bug in their application because
they're using an old timezone database, that is their problem, so long
as *we* ensure there is a clear and obvious mechanism for upgrading
*just* the TZ database, without upgrading Python itself. There's
nothing forcing people to keep their installed version of pytz up to
date, either.

If a timezone database is bundled into the standard library, there are
3 clear mechanisms for encouraging the use of fresh TZ data:

1. Consider TZ database updates to be bug fixes, and thus include them
in maintenance releases. This will keep the provided version
reasonably fresh for Python versions that are still in maintenance
mode.
2. Provide a mechanism to prefer the database from PyPI.
3. Provide a mechanism to prefer the OS database for platforms that
provide an Olson compatible interface (I briefly looked into that for
Windows a while back - it doesn't seem like a practical idea, since
Microsoft went off and did their own thing. It works for Linux and
other platforms that use the Olson database natively, though)

Since explicit is better than implicit, I *wouldn't* want to see
magical side affects where merely installing the database from PyPI,
or switching from Windows to Linux caused different behaviour.
However, it should be very easy for an application or environment to
*explicitly request* the use of the pytz database or the OS database
in preference to the bundled database.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia