zdump -v Europe/Helsinki | head -5 gives

Europe/Helsinki  Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki  Sat Apr 30 22:20:08 1921 UTC = Sun May
 1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 21:59:59 1942 UTC = Thu Apr
 2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki  Thu Apr  2 22:00:00 1942 UTC = Fri Apr
 3 01:00:00 1942 EEST isdst=1 gmtoff=10800

Python 2.4.1 (#1, May 16 2005, 15:19:29) 
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
  File "<input>", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->> 

Logged In: YES 
user_id=31435

What's this?

>>> from dateutil import tz

There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).

Logged In: YES 
user_id=861953

The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.

Logged In: YES 
user_id=861953

What do you think is best solution?

1) Python datetime is changed to tolerate more.

2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?

3) The python-dateutil tz library is changed to touch the
information provided by the operating system.

Logged In: YES 
user_id=31435

I don't know that this needs "a solution", but doubt
anything relevant is going to change in Python regardless --
that utcoffset() must return a whole number of minutes has
been documented from the start, and in several years hasn't
caused anyone else a problem.

Do you really believe that Helsinki was once 99 minutes and
52 seconds off from UTC?  I don't ;-)  Seems more likely
that your installation's time zone info is corrupt; that
this specific piece of historical time zone info is wrong
but nobody noticed before ("historical" because it's
certainly not the case that Helsinki is ever 5992 seconds
off from UTC in current reality); or that `dateutil` has a
relevant error.

Logged In: YES 
user_id=861953

I need a solution for this. Either I need to work around it
myself or I need to create a patched version of python or
dateutil.

We can't compare datetimes with tzinfos with datetimes
without tzinfos. This means that I either have tzinfo for
every datetime or for none. I prefer having them. Mostly I
am handling recent or future times, but I do want to have
some a bit older times too. It is not a problem if those
older times are not that exact, but I really don't want
those to cause errors. I ran into this while trying to
import data to my software and the whole import failed
because of this.

I really don't know what the offset was. Maybe the tzdata
people have some reason for it, maybe it is a bug with them.
 But I don't see myself going to tell them that they need to
change the data because python does not work with it. How
could I be sure that they would change all such occurrences
and wouldn't do it again?

My preferred solution would be that python datetime would
somehow tolerate it and not cause errors. It could even
round it to make it full minute. As these errors clearly
happen only with old times people rarely use, I don't see it
as a problem to make it a bit inaccurate.

If python won't change, then maybe I need to go and try to
say to dateutil people that they need to round the offsets
to avoid errors.

So, won't fix? :)

Closing: this is about 3rd party not following a documented API.