Re: [Python-ideas] [Python-Dev] datetime module enhancements
[Moving to python-ideas...]
On 3/9/07, Steven Bethard
On 3/9/07, Collin Winter
wrote on python-dev: One solution that just occurred to me -- and that skirts the issue of choosing an interpretation -- is that, when comparing date and datetime objects, the datetime's .date() method is called and the result of that call is compared to the original date. That is,
datetime_obj < date_obj
is implicitly equivalent to
datetime_obj.date() < date_obj
Using the .date() is fine when the year/month/day doesn't match. So the following are fine:: datetime.datetime(2005, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1) datetime.datetime(2007, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1) It's *not* okay to say that a date() is less than, greater than or equal to a datetime() if the year/month/day *does* match. The correct temporal relation is During, but Python doesn't have a During operator. During is not the same as less-than, greater-than or equal-to, so all of these should be False:: datetime.datetime(2006, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1) datetime.datetime(2006, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1) datetime.datetime(2006, 1, 1, 0, 0, 0) == datetime.date(2006, 1, 1) That is, the datetime() is not less than, greater than or equal to the corresponding date().
Some discussion of these kinds of issues is here: http://citeseer.ist.psu.edu/allen94actions.html The essence is that in order to properly compare intervals, you need the Meets, Overlaps, Starts, During and Finishes operators in addition to the Before (<) and Simulaneous (=) operators.
So, let's not conflate Before, After or Simultaneous with the other relations -- if it's not strictly Before (<), After (>) or Simultaneous (=), we can just say so by returning False.
It might be neat to add a __contains__ method to date() objects so that "datetime(2007, 1, 1, 0, 0, 0) in date(2007, 1, 1)" would be True. This would seem to fulfill the During operator. Collin Winter
Collin Winter wrote:
It might be neat to add a __contains__ method to date() objects so that "datetime(2007, 1, 1, 0, 0, 0) in date(2007, 1, 1)" would be True. This would seem to fulfill the During operator.
Yeah, I had the same idea: http://permalink.gmane.org/gmane.comp.python.devel/86828 In my opinion the comparison operations for date and datetime object should be defined as: datetime before date: < -----------------------
datetime(2007, 1, 1, 23, 59, 59) < date(2007, 1, 2) True Valid for all datetimes before (smaller than) datetime(2007, 1, 2, 0, 0, 0)
datetime during date: in ------------------------
datetime(2007, 1, 2, 23, 59, 59) in date(2007, 1, 2) True Valid for all datetimes((2007, 1, 2, *, *, *).date() == date(2007, 1, 2)
datetime after date: > ----------------------
datetime(2007, 1, 3, 0, 0, 0) in date(2007, 1, 2) True Valid for all datetimes after 2007-01-02 (greater or equal 2007-01-03 00:00:00)
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date. Christian
On 3/12/07, Christian Heimes
datetime before date: < datetime during date: in datetime after date: >
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date.
As a practical matter, sorting uses <=
I would be somewhat annoyed if
dt < d
were True, but when I tried to sort them,
dt <= d
raised a TypeError.
It would be OK with me to raise an error (ValueError?) on "dt <= d" if
"dt in d". Others might feel differently, and prefer to always get
the TypeError -- which is probably why dt
Jim Jewett wrote:
It would be OK with me to raise an error (ValueError?) on "dt <= d" if "dt in d". Others might feel differently, and prefer to always get the TypeError -- which is probably why dt
Seems to me that given all the conflicting behaviours peole want this to have in different circumstances, refusing to compare dates and datetimes is the right thing to do. All the use cases I've seen here for comparing them are easily accommodated by either extracting a date from the datetime to compare with the other date, or deriving a datetime from the date with whatever default time part you want. EIBTI. -- Greg
On 3/12/07, Greg Ewing
Jim Jewett wrote:
It would be OK with me to raise an error (ValueError?) on "dt <= d" if "dt in d". Others might feel differently, and prefer to always get the TypeError -- which is probably why dt
Seems to me that given all the conflicting behaviours peole want this to have in different circumstances, refusing to compare dates and datetimes is the right thing to do.
Right. A lot of thought went into this when the original design was done. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 3/12/07, Greg Ewing
Jim Jewett wrote:
It would be OK with me to raise an error (ValueError?) on "dt <= d" if "dt in d". Others might feel differently, and prefer to always get the TypeError -- which is probably why dt
Seems to me that given all the conflicting behaviours peole want this to have in different circumstances, refusing to compare dates and datetimes is the right thing to do.
The "conflicting behaviors" are really just at the boundaries, and the only reason they're "conflicting" is because people don't really seem to know yet what they need. This is probably an indication that an appropriately extended datetime module should be distributed as a third-party module for a while first... STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy
participants (6)
-
Christian Heimes
-
Collin Winter
-
Greg Ewing
-
Guido van Rossum
-
Jim Jewett
-
Steven Bethard