Issue 1447945: Unable to stringify datetime with tzinfo (original) (raw)
Created on 2006-03-11 18:51 by biny, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (8)
Author: Ilpo Nyyssönen (biny)
Date: 2006-03-11 18:51
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 "", 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) ->>
Author: Tim Peters (tim.peters) * 
Date: 2006-03-11 18:58
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).
Author: Ilpo Nyyssönen (biny)
Date: 2006-03-11 19:06
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.
Author: Ilpo Nyyssönen (biny)
Date: 2006-03-11 19:12
Logged In: YES user_id=861953
What do you think is best solution?
Python datetime is changed to tolerate more.
Linux tzdata package is changed to contain only full minute offsets. Who is going to convince them that this is good idea?
The python-dateutil tz library is changed to touch the information provided by the operating system.
Author: Tim Peters (tim.peters) *
Date: 2006-03-11 20:38
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.
Author: Ilpo Nyyssönen (biny)
Date: 2006-03-12 05:49
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.
Author: Daniel Diniz (ajaksu2) * 
Date: 2009-03-21 01:35
So, won't fix? :)
Author: Daniel Diniz (ajaksu2) *
Date: 2009-03-30 01:51
Closing: this is about 3rd party not following a documented API.
History
Date
User
Action
Args
2022-04-11 14:56:15
admin
set
github: 43016
2009-03-30 01:51:18
ajaksu2
set
status: pending -> closed
resolution: wont fix
messages: +
2009-03-21 01:35:59
ajaksu2
set
status: open -> pending
priority: normal -> low
type: behavior
versions: + 3rd party, - Python 2.4
nosy: + ajaksu2
messages: +
stage: test needed
2006-03-11 18:51:38
biny
create