On 3/31/2012 6:28 AM, Michael Foord wrote:
On 31 Mar 2012, at 07:32, Lennart Regebro wrote:
On Fri, Mar 30, 2012 at 12:38, Serhiy
Storchaka<storch...@gmail.com> wrote:
I don't understand why Python may not include the pytz. The Olson
tz database is not part of pytz.
Yes it is.
Python can depend on a system tz database
That works on Unix, but not on Windows, where there is no Olsen
database.
*However*, doesn't Windows have its own system database? The problem
is that in order to not include the olsen database, pytz (which would
be a very useful addition to the standard library) would need to be
modified to use the system database on Windows. This is my
(potentially flawed) understanding, anyway.
The Windows installer, by default, installs tcl/tk while Python on other
systems uses the system install. Why can't we do the same for the Olson
database?
As for updates: The correct behavior for timezone functions is to use
the most recent definitions of those functions. The date is an input
parameter for those functions. Projection of correct behavior for
today's date into the future is provisional and subject to correction.
This is especially true of anything involving Daylight Stupid Time. (As
you can tell, I would have it go away.) Testing the specific output of
such functions with future dates is broken.
So I think we should define correct behavior of pytz as use with the
latest Olson database. Use with an older version would then be a 'bug'
subject to being fixed. On Windows, we could update as needed with every
bugfix release. (And give instructions for user update.) On other
systems, users can do whatever is appropriate. Or perhaps we could add
an 'update tz database' function to the module.
Similary, our unicode implementation is defined as using the unicode
database as of a few weeks before each feature release. Updates for
bugfix releases are not done because changes to that database are a few
additions each time rather than edits.
--
As a side note: I think the same trick of defining correct behavior
dynamically rather that statically could be applied to other modules,
such mimetypes and internet protocol modules. This seems to be part of
the intent of the idea of having stdlib feature releases every 6 months
or so.
--
Terry Jan Reedy
_______________________________________________
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
