[Python-Dev] Stdlib and timezones, again

[Matthias Klose]

On 01.10.2012 00:50, Gregory P. Smith wrote:
> On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose <doko at 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 at python.org
>>> wrote:
>>>
>>>> 2012/9/30 Xavier Morel <python-dev at 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.

I would add

 - a 2.5) if pytzdata does exist and uses the tz data from the underlying
operating system.
 - a 3.5) if pytzdata does exist and doesn't use the tz data from the underlying
operating system.

however I see our patch to pytzdata to use the os data is a local patch, and not
found upstream.

  Matthias