Re: comparing datetime with date

Discussion in 'Python' started by Andrew Durdin, Sep 15, 2004.

  1. On Tue, 14 Sep 2004 17:16:58 -0400, Tim Peters <> wrote:
    > [Donnal Walter]
    > > I was very surprised to discover that
    > >
    > > >>> import datetime
    > > >>> x = datetime.date(2004, 9, 14)
    > > >>> y = datetime.datetime(2004, 9, 14, 6, 43, 15)
    > > >>> print x == y

    > > True
    > >
    > > How can these two objects be considered equal?

    >
    > They should not be. Please open a bug report. The problem is due to that
    > datetime.datetime is a subclass of datetime.date:


    Why should this be considered a bug? In my conception, a datetime.date
    covers the whole range of times within the date, so that this equality
    makes sense. It also allows for intuitive inequality comparisons
    between datetime.datetime and datetime.date.

    To make that more clear, it makes sense to me that comparisons between
    datetime.datetime and datetime.date should only compare the date part,
    and those between datetime.datetime and datetime.time should only
    compare the time part. This latter however throws an exception; I
    infer from that that the 'pythonic' way is to explicitly make a
    datetime.date or datetime.time from the datetime.datetime before
    comparing. So I guess I've answered my own question :)
     
    Andrew Durdin, Sep 15, 2004
    #1
    1. Advertising

  2. Andrew Durdin

    Steve Holden Guest

    Andrew Durdin wrote:

    > On Tue, 14 Sep 2004 17:16:58 -0400, Tim Peters <> wrote:
    >
    >>[Donnal Walter]
    >>
    >>>I was very surprised to discover that
    >>>
    >>>
    >>>>>>import datetime
    >>>>>>x = datetime.date(2004, 9, 14)
    >>>>>>y = datetime.datetime(2004, 9, 14, 6, 43, 15)
    >>>>>>print x == y
    >>>
    >>>True
    >>>
    >>>How can these two objects be considered equal?

    >>
    >>They should not be. Please open a bug report. The problem is due to that
    >>datetime.datetime is a subclass of datetime.date:

    >
    >
    > Why should this be considered a bug? In my conception, a datetime.date
    > covers the whole range of times within the date, so that this equality
    > makes sense. It also allows for intuitive inequality comparisons
    > between datetime.datetime and datetime.date.
    >

    Well you do, of course, allow that this appeals to *your* intuition, but
    it seems much more reasonable to me to assume that a date, when compared
    to a datetime, should specify a single canonical time (such as midnight
    at the start of that date).

    > To make that more clear, it makes sense to me that comparisons between
    > datetime.datetime and datetime.date should only compare the date part,
    > and those between datetime.datetime and datetime.time should only
    > compare the time part. This latter however throws an exception; I
    > infer from that that the 'pythonic' way is to explicitly make a
    > datetime.date or datetime.time from the datetime.datetime before
    > comparing. So I guess I've answered my own question :)


    Comparing a datetime and a time makes little sense to me, and I'd prefer
    to be forced to extract the time explicitly from the datetime before
    comparison. A time specifies a point during *any* day, a datetime
    specifies a single point in the time continuum.

    When all's said and done I guess this thread mostly highlights the
    unsatisfactory aspects of intuition when used as a basis for agreement
    on complex software specifications :)

    regards
    Steve
     
    Steve Holden, Sep 15, 2004
    #2
    1. Advertising

  3. Steve Holden wrote:
    > Comparing a datetime and a time makes little sense to me, and I'd prefer
    > to be forced to extract the time explicitly from the datetime before
    > comparison. A time specifies a point during *any* day, a datetime
    > specifies a single point in the time continuum.


    Perhaps I am guilty of not explaining what I was trying to do. I have an
    abstract class (called Cell) that implements a form of the observable
    pattern. When x.set(...) is called, it check to see if the new value is
    different from the old value before making the change and notifying
    observers. The abstract Cell class has a lot of other functionality, as
    well, but this is the critical feature. Then I have at least three
    subclasses: one for text (strings), one for numbers, and one for
    timepoints. Althought the internal value representation is different for
    all three, they all use the same basic set(...) method. In my first
    implementation, the internal representation for TimePoint was going to
    be a datetime.datetime object. Sometimes, however, one knows a date
    without knowing the time (date of birth, for example, before knowing the
    time of birth, and this is important in newborn intensive care). I
    wanted to be able to enter the date of birth in a way that indicates
    that the time is unknown at present, so I used a datetime.date. Then
    later after the actual time is learned, it could be changed to a
    datetime.datetime. How else would the associated presenter (presentation
    object) know whether or not the time was unknown? But this means that
    for my implementation dt.date should not evaluate as equal to the
    corresponding dt.datetime.

    My solution now (as a result of this thread) is to use a three-tuple for
    date of birth and a five-tuple for date and time of birth. These two
    representations obviously do evaluate as different. I still convert to
    datetime.datetime (with or without DST information) for calculations of
    intervals, but storage is the basic time tuple.

    Kind regards,
    Donnal Walter
    Arkansas Children's Hospital
     
    Donnal Walter, Sep 15, 2004
    #3
  4. Steve Holden <> wrote:

    > > Why should this be considered a bug? In my conception, a datetime.date
    > > covers the whole range of times within the date, so that this equality
    > > makes sense. It also allows for intuitive inequality comparisons
    > > between datetime.datetime and datetime.date.
    > >

    > Well you do, of course, allow that this appeals to *your* intuition, but
    > it seems much more reasonable to me to assume that a date, when compared
    > to a datetime, should specify a single canonical time (such as midnight
    > at the start of that date).


    I have no opinion on the specific semantics so I prefer to look at the
    logic of this... if we allow a date to compare equal to many different
    datetimes, then we have a situation in which:

    a == b

    AND

    a == c

    BUT NOT

    b == c

    !!!
    (just pick a as a date, b and c as two different datetimes within
    it...).

    This means == does not define an equivalence relationship, and THAT is
    enough to send me into shivers and cold sweating. Either having a
    comparison between date and datetime raise an exception, or consider a
    date to be == to ONE specific datetime, will be OK from this POV. As
    for which choice is better, if I was the one tasked to design this, I'd
    go for "In the face of ambiguity, refuse the temptation to guess", and
    raise an exception. But I don't feel particularly strongly about this.


    Alex
     
    Alex Martelli, Sep 15, 2004
    #4
  5. Andrew Durdin

    Tim Peters Guest

    [Alex Martelli, on comparing datetime to date objects]
    > I have no opinion on the specific semantics so I prefer to look at the
    > logic of this... if we allow a date to compare equal to many different
    > datetimes, then we have a situation in which:
    >
    > a == b
    >
    > AND
    >
    > a == c
    >
    > BUT NOT
    >
    > b == c
    >
    > !!!
    > (just pick a as a date, b and c as two different datetimes within
    > it...).
    >
    > This means == does not define an equivalence relationship, and THAT is
    > enough to send me into shivers and cold sweating. Either having a
    > comparison between date and datetime raise an exception, or consider a
    > date to be == to ONE specific datetime, will be OK from this POV. As
    > for which choice is better, if I was the one tasked to design this, I'd
    > go for "In the face of ambiguity, refuse the temptation to guess", and
    > raise an exception. But I don't feel particularly strongly about this.


    The twist here is that datetime derives from date, and an object of a
    class C usually thinks it's OK to compare itself with an object of a C
    subclass. Sometimes that's appropriate, sometimes not. I agree it's
    inappropriate in this case.

    I expect that datetime_richcompare() needs to a grow a wart refusing
    to allow delegation to date_richcompare() when "the other" argument is
    not an instance of datetime but is an instance of date (BTW,
    datetime_richcompare() does get first crack at doing the comparison,
    because some hairy runtime code gives first crack to the object of the
    more specific class when there's a subtype relationship between the
    comparands' classes).
     
    Tim Peters, Sep 15, 2004
    #5
  6. > Steve Holden <> wrote:
    >
    > > Well you do, of course, allow that this appeals to *your* intuition, but
    > > it seems much more reasonable to me to assume that a date, when compared
    > > to a datetime, should specify a single canonical time (such as midnight
    > > at the start of that date).


    My POV mostly comes from having to deal with comparing a date to an
    inclusive range of dates (i.e. time is unimportant) where the dates
    are stored (implicitly) as datetimes with a midnight time: 3/9/04 <= x
    <= 17/9/04 (using dd/mm/yy)
    In this case, the equality will fail if x happens to be 17/9/04
    00:00:01 or later, and the solution of having to increment the day of
    the right endpoint of the range is both inconvenient and non-obvious
    (when reading the code). Of course, python's separate datetime, date,
    and time types allow for a better solution to this problem: use the
    date type only.

    On Wed, 15 Sep 2004 16:13:28 +0200, Alex Martelli <> wrote:
    > This means == does not define an equivalence relationship, and THAT is
    > enough to send me into shivers and cold sweating. Either having a
    > comparison between date and datetime raise an exception, or consider a
    > date to be == to ONE specific datetime, will be OK from this POV. As
    > for which choice is better, if I was the one tasked to design this, I'd
    > go for "In the face of ambiguity, refuse the temptation to guess", and
    > raise an exception. But I don't feel particularly strongly about this.


    It looks like there are some discrepancies between comparison handling
    between the datetime types, though:
    >>> import datetime
    >>> d = datetime.date(2004,9,17)
    >>> t = datetime.time(10,28,47)
    >>> dt = datetime.datetime(2004,9,17,10,28,47)
    >>> dt == d

    True
    >>> dt == t

    False
    >>> d == t

    False
    >>> dt < d

    False
    >>> dt < t

    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    TypeError: can't compare datetime.datetime to datetime.time
    >>> d < t

    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    TypeError: can't compare datetime.date to datetime.time

    You can compare a datetime and a time for equality, but not for
    inequality. A datetime and date can be compared for both. It is
    probably better to raise an exception for any comparison between time
    and datetime, time and date, or date and datetime. If the former or
    latter are desired, then the date() and time() methods of the datetime
    object can be used to explicitly get a comparable object.
     
    Andrew Durdin, Sep 17, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christos TZOTZIOY Georgiou
    Replies:
    3
    Views:
    743
    Christos TZOTZIOY Georgiou
    Sep 13, 2003
  2. Tim Peters
    Replies:
    0
    Views:
    580
    Tim Peters
    Sep 9, 2003
  3. mp
    Replies:
    1
    Views:
    417
    John Machin
    Jul 28, 2006
  4. Martin
    Replies:
    0
    Views:
    362
    Martin
    Dec 27, 2008
  5. Replies:
    2
    Views:
    788
    M.-A. Lemburg
    Jan 6, 2009
Loading...

Share This Page