[Python-ideas] lack of time zone support

[Brett Cannon]

On Tue, Jun 1, 2010 at 11:32, Bill Janssen <janssen at parc.com> wrote:
> To me, the single most irritating problem with the Python support for
> date/time is the lack of support for time-zone understanding.  This
> breaks down into two major issues, %z and lack of a standard time-zone
> table.
>
> First, let's say I have to parse a Medusa log file, which contains time
> stamps in the form "DD/Mon/YYYY:HH:MM:SS [+|-]HHMM", e.g.
> "31/May/2010:07:10:04 -0800".  What I'd like to write is
>
>  tm = time.mktime(time.strptime(timestamp, "%d/%b/%Y:%H:%M:%S %z"))
>
> which is what I'd do if I was writing in C.  But no!  The Python
> _strptime module doesn't support "%z".  So instead, I have to pick the
> timestamp apart and do things separately and remember that "-0800" isn't
> octal, and also isn't the same as -800, and remember whether to add or
> subtract it.  This seems insane.  So, IMO, support for %z should be
> added to Lib/_strptime.py.  We need a patch.
>
> Secondly, we really need concrete subclasses of tzinfo, and some sort of
> mapping.  Lots of people have spent lots of time trying to figure out
> this cryptic hint in datetime: "The datetime module does not supply any
> concrete subclasses of tzinfo."  I'm not sure whether pytz is the best
> ideas, or what I use, the "zoneinfo" module from python-dateutil.  With
> that, I still have to add the Windows timezone names, using the table at
> http://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml,
> because the code in python-dateutil only works with Windows timezone
> names when running on Windows.

First of all, there will never be a timezone table in the stdlib,
period. This has been brought up before and is always shot down
because python-dev does not want to have to keep track of timezone
changes. pytz and other modules fit that bill fine.

Now if you want UTC, that's different. Alexander already linked to an
issue that is discussing that end. The current proposal is to provide
a generic class that creates fixed UTC-offset timezones, with an
instance for UTC set on the datetime module.

If you get that class in, you could then patch _strptime to support
the %z directive so as to return a timezone that had a set UTC-offset.
Not optimal, but it's something. Otherwise you would need to patch
_strptime to simply consume the number which I don't think anyone
wants.