This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author biny
Recipients
Date 2006-03-12.05:49:24
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2008-01-20 09:58:31adminlinkissue1447945 messages
2008-01-20 09:58:31admincreate