On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose <doko@ubuntu.com> wrote:
On 30.09.2012 20:18, Gregory P. Smith wrote:
> On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson <benjamin@python.org>wrote:
>
>> 2012/9/30 Xavier Morel <python-dev@masklinn.net>:
>>> But at worst, an outdated unicode database will be missing data right?
>>>
>>> Doesn't an outdated timezone db have the risk of returning *incorrect*
>> data?
>>
>> Unicode updates also include corrections; however, it seems there are
>> not significant enough or about obscure enough scripts that not many
>> notice. :)
>>
>
> We never hear anyone complain because the corrections are not for English
> or other "western" languages that the majority of us speak.  ;)
>
> Regardless, I think including a version of the database on windows releases
> makes sense.  Update it on a best effort basis before each .x minor
> release.  The documentation can make it clear that it is a changing
> database how to use an updated version with your application.
>
> One additional thing I'd like to see: Don't let the successful importing of
> a 'pytzdata' module be the only way to get an updated tz database.  Create
> an API for someone to supply one themselves at runtime that is cleaner than
> shoving something into sys.modules['pytzdata'].  And define in which order
> they'll be used:
>
> priority:
>   1) api call supplying tz data to the process.
>   2) pytzdata module if it exists
>   3) tz data from the underlying operating system
>   4) error.

I disagree on this order, at least for Linux systems. the tzdata database is
well managed on major Linux distributions and should be used for this reason.

Agreed, but that is why anyone writing code for Linux will simply never use 1) or 2).  Those exist primarily to handle the Windows and people with software running on non well managed systems.

I'd add a 3.5) to the above list: tz data bundled with the Python distribution.  Bundled tz data would likely simply not even be included in a Python package on a Linux system.

-gps