[Python-Dev] datetime module enhancements

[Steven Bethard]

On 3/10/07, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
> Steven Bethard <steven.bethard at gmail.com> wrote:
> > 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.
>
> Why not? That only makes sense if you decide that a Python 'date'
> means 'the entire of that day'. It's not at all clear that that's
> what a Python 'date' *does* mean. And, as I mentioned before, if
> you do decide that then what Python currently does when you
> subtract dates is broken.

No, as Phillip J. Eby pointed out, there's a variety of ways to define
subtraction over intervals:
(1) Distance between start1 and start2
(2) Distance between start1 and end2
(3) Distance between end1 and start2
(4) Distance between end1 and end2
Options (1) and (4) are consistent with the current implementation.
Options (2) and (3) are not.  I don't see why the docs can't be
explicit about what subtraction means given that there are a number of
possible interpretations.

> I just found another case where 'date's pretend to have a time-part
> of midnight - if you add a date to a timedelta. Add 23 hours to a
> date and it's unchanged - add 24 and it moves forward a day. If a
> 'date' really is 'the entire of that day', then adding a timedelta
> to it which is not an integer multiple of 1 day should either raise
> an exception, or return some 'time duration' object that doesn't
> currently exist.

You can draw the analogy here with integer addition::

    >>> int(1) + int(.75)
    1
    >>> int(1) + int(1.25)
    2

Though if I had written the datetime module, this would have raised an
exception, rather than passing silently.  But I suspect that almost no
one is adding *hours* to *dates* so I don't particularly care how it
behaves, nor do I think that some idiosyncratic behavior in a part of
the module no one uses should dictate the behavior in the rest of the
module.

> Your argument is quite correct if you're considering some fancy
> uber-complicated kitchen-sink-included all-encompassing "temporal
> logic package", but that's not what Python's datetime is, nor
> frankly is what it should be.

I'm not expecting Python's datetime module to handle any complex
temporal logic.  But boy it would be nice if it didn't *break* basic
temporal logic, and that's certainly possible with a very small bit of
effort.  However, assuming that a date() is a datetime() with a time
of midnight will clearly break that logic.

I still don't see why my more careful comparison would be bad for any
of your code. Could you give an example where it would be bad for all
the following to be False::
     date(2006, 1, 1) < datetime(2006, 1, 1, 0, 0, 0)
     date(2006, 1, 1) > datetime(2006, 1, 1, 0, 0, 0)
     date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0)
even though the following would be True::
     date(2006, 1, 1) < datetime(2006, 1, 2, 0, 0, 0)
     date(2006, 1, 1) > datetime(2005, 12, 31, 0, 0, 0)
?

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