On Thu, Feb 18, 2010 at 4:38 PM, Lennart Regebro <rege...@gmail.com> wrote:

If it doesn't solve a problem, it shouldn't be done, as it also is
going to create problems, because everything does. :)

I think a tzinfo implementation in the standard library that uses the system 
timezone database would be useful to a great many people, providing a standard 
way of mapping a string to a tzinfo instance. The number of frameworks 
requiring pytz as a dependency demonstrate this.

It is unfortunate that those strings would be platform specific. For most 
applications this doesn't matter - you are reading the key from a config file 
or allowing the user to select from a list of possible values.

For applications where that actually matters it would be simple enough to install and maintain a local zoneinfo database, for example by allowing pytz to plug itself in or just a well known location in the Python tree where valid compiled zoneinfo files can be copied in from a nearby unix-like system or pytz tarball.
As the pytz maintainer, this would help me solve a long standing problem. 
Currently, pytz tzinfo instances don't really follow the documented tzinfo 
interface (in order to allow localized datetime arithmetic to be always correct 
instead of good enough). This is a source of confusion to many users who don't 
need this level of accuracy. It would be great if the standard library provided 
a tzinfo implementation that was good enough for the vast majority of users, 
and for people who do care they can continue to use pytz.timezone() to retrieve 
the anal tzinfo implementation. Users will be happier as they will have fewer 
bugs in their code. The alternative for me is to eventually split pytz, somehow 
providing the simpler interface that works exactly as documented in the Python 
reference and the anal interface that works per the pytz README (in hindsight, 
it should have been this way from day 1).

I'm happy to work on this if there is agreement. I'm happy to relicense any pytz code used as a basis if necessary (currently MIT), and dateutil is already PSF licensed if that seems a better starting point.
--
Stuart Bishop <stu...@stuartbishop.net>
http://www.stuartbishop.net/

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to