I'm personally +1 for pytz only — dateutil is big enough and... Well, can we just point to pytz in our docs for datetime module? On Thu, Mar 29, 2012 at 12:06 AM, Guido van Rossum wrote:

+1 If pytz is py3k cabable. -1 for dateutIl.

On Wednesday, March 28, 2012, Andrew Svetlov wrote:

...

I figured out what pytz and dateutil are not mentioned in python docs for datetime module. It's clean why these libs is not a part of Python Libraries — but that's not clean for Docs. From my perspective at least pytz (as py3k compatible) should to be mentioned as the library which contains timezone info, supported carefully and recommended to use with datetime standard module,

-- Thanks, Andrew Svetlov _______________________________________________ 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/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

-- Thanks, Andrew Svetlov

On Fri, 30 Mar 2012 13:38:13 +0300, Serhiy Storchaka wrote:

28.03.12 23:20, Andrew Svetlov написав(ла):

...

I figured out what pytz and dateutil are not mentioned in python docs for datetime module. It's clean why these libs is not a part of Python Libraries — but that's not clean for Docs.

I don't understand why Python may not include the pytz. The Olson tz database is not part of pytz. Python can depend on a system tz database, as it depends on libssl or libbz2, which also can be updated (for security reasons) independently.

There is an extensive discussion of this somewhere in the archives of this list. If I remember correctly, it boils down to the fact that pytz does bundle the database, and that Windows either does not have or does not regularly update its own Olson database. Rather than ship something out-of-date, we choose to put the onus on the user to ensure that the appropriate code+db exists on their system. Hopefully someone will correct me if I'm wrong, and/or find a pointer to the relevant thread. --David

On Fri, Mar 30, 2012 at 10:47 PM, R. David Murray wrote:

On Fri, 30 Mar 2012 13:38:13 +0300, Serhiy Storchaka wrote:

...

28.03.12 23:20, Andrew Svetlov написав(ла):

...

I figured out what pytz and dateutil are not mentioned in python docs for datetime module. It's clean why these libs is not a part of Python Libraries — but that's not clean for Docs.

I don't understand why Python may not include the pytz. The Olson tz database is not part of pytz. Python can depend on a system tz database, as it depends on libssl or libbz2, which also can be updated (for security reasons) independently.

There is an extensive discussion of this somewhere in the archives of this list.  If I remember correctly, it boils down to the fact that pytz does bundle the database, and that Windows either does not have or does not regularly update its own Olson database.  Rather than ship something out-of-date, we choose to put the onus on the user to ensure that the appropriate code+db exists on their system.

Hopefully someone will correct me if I'm wrong, and/or find a pointer to the relevant thread.

That's my recollection as well. Because we don't want to take on the task of providely timely updates in response to timezone database changes, any named timezone support added to the stdlib would need to be based on a system provided timezone database, rather than the bundled database model used by pytz. This is straightforward on *nix based systems that provide the zoneinfo structure in the filesystem, but more complicated on Windows (which has its own custom scheme). Before the idea of adding full timezone support to the standard library could be seriously considered someone would have to, at the very least, use the mapping data from the Unicode Consortium's CLDR Supplementary data to map the standard Olsen database timezone names to the correct values to look up through the Windows timezone APIs (http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html) Adding mappings for *new* timezones would still be controlled by our release cycle (although I think it would be reasonable to permit such additions in maintenance releases), but updates in response to things like daylight savings dates changing would then be the responsibility of the OS vendors. However, "pip install pytz" is easy enough that there isn't a lot of motivation for anyone to do the work to switch from a bundled copy of the timezone database to a bundled TZID -> Windows API lookup mapping. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 31 Mar 2012, at 07:32, Lennart Regebro wrote:

On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka 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. Michael

//Lennart _______________________________________________ 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/fuzzyman%40voidspace.org.u...

-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

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

On Sat, Mar 31, 2012 at 21:20, Terry Reedy wrote:

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?

The problem is that it needs updating. We could include pytz, but it would be useless on Windows, unless you also separately installs the Olson database. But including it and updating it is not Python's job and should not be. //Lennart