[Python-Dev] datetime module enhancements (original) (raw)

Steven Bethard steven.bethard at gmail.com
Sat Mar 10 18:53:35 CET 2007

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

More information about the Python-Dev mailing list