On 06/02/10 10:50, Brett Cannon wrote:
On Tue, Jun 1, 2010 at 11:32, Bill Janssen
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.
Has a module to pull timezone data from the OS been proposed before?