[dateutil] bug(s) in dateutil.parser /dateutil.tz

[jholg]

Hi all,

I'm having some problems with python-datetutil (which is a very, very nice tool, btw). Anybody knows where to adress these other than here? I tried reaching the author but don't seem to get through.

Anyhow:
1. There's a bug in dateutil.parser you run into when you try to use a custom parserinfo. This patch fixes it:

*** /data/pydev/DOWNLOADS/python-dateutil-1.1/dateutil/parser.py.ORIG Mon Nov 6 15:39:26 2006
--- /data/pydev/DOWNLOADS/python-dateutil-1.1/dateutil/parser.py Mon Nov 6 15:39:46 2006
***************
*** 285,291 ****

def __init__(self, info=parserinfo):
if issubclass(info, parserinfo):
! self.info = parserinfo()
elif isinstance(info, parserinfo):
self.info = info
else:
--- 285,291 ----

def __init__(self, info=parserinfo):
if issubclass(info, parserinfo):
! self.info = info()
elif isinstance(info, parserinfo):
self.info = info
else:


2. There is another bug in dateutil.tz in the tzfile class.
This is a section of the Solaris MET zoninfo file

$ zdump -v MET|grep 1982
MET Sun Mar 28 00:59:59 1982 UTC = Sun Mar 28 01:59:59 1982 MET isdst=0
MET Sun Mar 28 01:00:00 1982 UTC = Sun Mar 28 03:00:00 1982 MEST isdst=1
MET Sun Sep 26 00:59:59 1982 UTC = Sun Sep 26 02:59:59 1982 MEST isdst=1
MET Sun Sep 26 01:00:00 1982 UTC = Sun Sep 26 02:00:00 1982 MET isdst=0

Using this with tz.tzfile:

Note how the MET local time is wrong at 23:59UTC, 0:59UTC and 01:59UTC.

I've looked at the code but currently don't really understand how the default tzfinfo.fromutc implementation, as quoted in the python datetime documentation, is supposed to work in the first place.

Any ideas?

Cheers,
Holger