On Tue, Feb 16, 2010 at 11:18 PM, Tres Seaver <tsea...@palladion.com> wrote:
> Dirkjan Ochtman wrote: >> On Tue, Feb 16, 2010 at 16:26, Tres Seaver <tsea...@palladion.com> wrote: >>> Because timezones are defined politically, they change frequently. pytz >>> is released frequently (multiple times per year) to accomodate those >>> changes: I can't see any way to preserve that flexibility if the >>> package were part of stdlib. >> >> By using what the OS provides. At least on Linux, the basic timezone >> data is usually updated by other means (at least on the distro I'm >> familiar with, it's updated quite often, too; through the package >> manager). I'm assuming Windows and OS X would also be able to provide >> something like this. I think pytz already looks at this data if it's >> available (precisely because it might well be newer). > > If that were so, I don't think Stuart would be going to the trouble to > re-release the library 6 - 12 times per year. The Debian, Ubuntu and I think Redhat packages all use the system zoneinfo database - there are hooks in there to support package maintainers that want to do this. This way the package can be included in the supported release but still receive timezone information updates via the OS (but no code updates, but these are rare and usually irrelevant unless you where the person who filed the bug ;) ). I'd be happy to rework pytz for the standard Library using the system installed zoneinfo database if it is available. I think for the standard library though, it needs to follow the documented API better rather than the .normalize() & .localize rubbish I needed to get localized datetime arithmetic working correctly. Having seen the confusion and bug reports over the last few years, I think people who need this are in the minority and pytz can still exist as a separate package to support them. tzwin could be used on Windows platforms - I'd need to look into that further to see if the API can remain consistent between *nix and Windows. I suspect that pytz without the .normalize() & .localize() rubbish may look remarkably similar to dateutil so that might be a better option to start from. We could consider extending the existing datetime library to support localized datetime arithmetic. This would either involve adding an extra bit to datetime instances to support the is_dst flag (originally deemed unacceptable as it increased the pickle size by a whole byte), or better support for tzinfo implementations to store the is_dst flag in the tzinfo instance (the approach pytz used). This requires a C programmer though and I'm so very, very rusty. I am not at pycon alas. Some of my coworkers from Canonical will be though and they might be interested as we use pytz for Launchpad and other Canonical projects. -- Stuart Bishop <stu...@stuartbishop.net> http://www.stuartbishop.net/ _______________________________________________ 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