[Python-Dev] datetime module and pytz with dateutil

[Terry Reedy]

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<storchaka at 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