The following demonstrates the problem: >>> from datetime import datetime,timedelta >>> datetime.now().date()+timedelta(hours=1) datetime.date(2008, 7, 1) I'd expect the above to either result in a TypeError or (preferably) datetime.datetime(2008, 7, 1, 1, 0)
This isn't "a bug", since it's functioning as documented and designed. Read note 1 in the "date Objects" section of the reference manual, explaining the meaning of "date2 = date1 + timedelta": """ date2 is moved forward in time if timedelta.days > 0, or backward if timedelta.days < 0. Afterward date2 - date1 == timedelta.days. timedelta.seconds and timedelta.microseconds are ignored. OverflowError is raised if date2.year would be smaller than MINYEAR or larger than MAXYEAR. """ ). You could call this a feature request instead, but an incompatible change to documented always-worked-this-way behavior is unlikely to be accepted.
This may be "as documented" but it's *extremely* counter intuitive and seems to go against the grain of where python is headed. (remember that whole struggle to get 3/2 = 1.5 rather 3/2=1? ;-) ) I've changed the "type" to "feature request", what's the best mailing list to kick off discussion about this?
To be valid, your analogy between dates and numbers suggests that a date should be convertible to the datetime with the same date, at midnight. And both objects compare equal, just like 42==42.0 But today this is not the case: it's hard to convert a date into a datetime, and types cannot be ordered: >>> datetime.date.today() < datetime.datetime.now() TypeError: can't compare datetime.datetime to datetime.date
Amaury, Yes, I agree with you, and that sucks too. I'd suggest opening another bug for that ;-) For an allegedly nice, shiny, new and perfect module, datetime sure seems to have an awful lot lacking... Chris
