[Python-Dev] datetime module enhancements

[Jon Ribbens]

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.

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.

> 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::

I think you're assuming the Python datetime module has higher goals
than it does. It doesn't have any concept of a duration in time,
not unless you couple a 'datetime' with a 'timedelta' yourself.
And 'timedelta's are restricted to periods of time that are a fixed
number of seconds - i.e. there is no way to indicate "a month"
or "a year" (although that lack is a whole different argument ;-) )

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.