[Python-Dev] Stdlib and timezones, again (original) (raw)
Matthias Klose doko at ubuntu.com
Mon Oct 1 00:57:31 CEST 2012
- Previous message: [Python-Dev] Stdlib and timezones, again
- Next message: [Python-Dev] Stdlib and timezones, again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Stdlib and timezones, again
- Next message: [Python-Dev] Stdlib and timezones, again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]