At 03:28 PM 5/27/2005 -0700, Andi Vajda wrote:
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
To compare a date with a datetime, use the datetime's '.date()' method to
downcast to a date; Python won't do the comparison because of the implicit
loss in precision.
So, if you spot a type error in a date comparison, and you're trying to
compare a simple date with a datetime, you need to convert the datetime to
a date, first.
- 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.
As each of these comparisons occurs at runtime, we'll get errors showing
where to fix them, so it shouldn't be a big deal to get them taken care of.
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.
What does it mean to compare at time with a timezone, with a time with no
timezone? If you want to treat a naive timestamp as one in the "local"
timezone, you can do:
aDateTime.replace(tzinfo=tzlocal)
(assuming you have a 'tzlocal' variable with a dateutil 'tzlocal()'
timezone instance in it.)
It might be better to make such conversions explicit.
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 ?
Yes, the conversion you want for that example is 'aDatetime.date() == today'.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
