With the recent change from mx date/time types to the python builtins there
are few new constraints to keep in mind. The python builtins are more strict
in several ways, some unfortunate:
- You cannot compare a date with a datetime object (and vice-versa) and that
is very unfortunate as to work this around you have to either:
- write custom comparison code
- initialize a datetime from the date by leaving the datetime time
fields 0 which leads to the next problem
- You cannot compare datetimes or times that are not the same in their
'naivete' (to use some unfortunate python terminology here, a datetime is
considered 'naive' when it doesn't have a time zone). When creating a
datetime from a date for sake of comparison you don't have a timezone to
initialize that datetime with since a date has no such thing, by
definition.
The calendar code (and its UI) is still working with the previous, mx-based,
assumptions. I couldn't fix that as it was very hard to know where what was
intended to do and work with, especially regarding the use of timezones which
is still being spec'ed out.
This message is just a heads up. For example, if you import the demo calendar,
when you render it, you get exactly such an error (about timezone and no
timezone types being compared). I did send a patch to Morgen working this
around with custom comparison methods but wasn't sure that was the right
approach.
It would all be easier from the standpoint of the calendar code if there was a
simple way to say test today < datetime < tomorrow but there doesn't seem to
be such a thing, or maybe I'm missing something ? Phillip, do you know ?
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
