[Python-Dev] Add UTC to 2.7 (PyCon sprint idea)

[Lennart Regebro]

On Tue, Feb 16, 2010 at 13:42, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Tue, Feb 16, 2010 at 13:05,  <skip at pobox.com> wrote:
>>    Maybe an alternate sprint idea would be to incorporate dateutil into the
>>    Python core: http://labix.org/python-dateutil
>>
>> Whoops...  (just waking up - still need that first cup of coffee)
>>
>> While incorporating dateutil into the core would be nice (in my opinion at
>> least), I was really thinking of pytz: http://pytz.sourceforge.net/
>
> I think dateutil is fairly heavy for the stdlib, but I think pytz
> would be a very good candidate for inclusion. Without it, the timezone
> support in datetime is hardly usable.

The timezone database is updated several times per year. You can *not*
include it in the standard library.

On Tue, Feb 16, 2010 at 16:43, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> By using what the OS provides.

The OS often does not.

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

The Windows timezone data sucks donkeyballs through a hose. Thus, if
the timezone implementations from pytz was in the standard library,
and the timezone data not, they would not be useable on Windows. So,
no can do. Also, different Unices often have slightly different names
and organisations of the Olsen database, which would create confusions
and incompatibilities, so that's probably also not the best solution.


== So, what to do? Use Pytz! ==
There is no need to stick Pytz in the standard library. It's available
on PyPI, updated frequently, etc. What we can do is point to it from
the documentation.

But before that, it needs a fix. Pytz is great, but missing one thing:
Wrappers for the current locale settings. This is necessary, because
there is no way of realiably figuring out the current locale. See
http://regebro.wordpress.com/2008/05/10/python-and-time-zones-part-2-the-beast-returns/
(and http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/
for other timezone issues).

These kinds of wrappers exist in dateutils.tz. It would be great if
that type of functionality could get into Pytz as well. A sprint to do
this and fix the issues in the tracker should solve the issues, I
think. There is no need to move things into the core. An Pytz could
use more maintainers, Stuart tends not to answer emails, I assume this
is because he is overw

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64