Can I just stop using datetime.date entirely?

Question

In Python, it's my impression that datetime.date is basically just a subset of datetime.datetime, with fewer features and slightly less overhead. I'd like to never use datetime.date again for the following reasons:

• No more conversions between the two types!

• datetime.date objects are always timezone-unaware, for obvious reasons. This makes it harder to generalize timezone handling across an entire application, if sometimes you're using datetime.date and sometimes you're using datetime.datetime

• On multiple occasions I've encountered headaches accidentally comparing datetime.date objects and datetime.datetime objects. Always using only one type makes comparisons simpler.

• Formatting differences between datetime.date and datetime.datetime should be a formatting issue only. Carrying the difference further down into the underlying class introduces an unnecessary complexity to the language.

• If I'm on the right track about this, then datetime.date will eventually be deprecated in future releases of Python, just like unicode and long have been. Adopting this convention now puts me ahead of the curve.

It seems to me that the only compelling argument for continuing to use datetime.date is small amount of extra memory and storage involved in datetime.datetime. Let's say that I don't care about this extra overhead. Are there any other very compelling reasons to keep using this class? I don't want to switch to this convention and then regret it later because I missed something important.

Answer 1

They represent different things.

A datetime is a specific point in time.

A date is an interval in time. It's not 00:00:00 on that day, it's the entire day.

That's why you can't directly convert between them. And that's why you cannot use datetime as a substitute for date.

(The fact that the same timedelta type is used for both is probably a flaw in the module, which has been discussed a few times, but I doubt that it will ever be corrected.)

Answer 2

This is the precise relationship:

>>> import datetime
>>> issubclass(datetime.datetime, datetime.date)
True

If you don't want to use date, simply don't. There are many applications in which the "small amount of extra memory and storage involved" for a datetime is a significant burden, especially when a massive number of dates need to be stored in a database as pickles (e.g., in ZODB in a Zope installation - and it's not coincidental that Zope Corp paid the then-PythonLabs team to design & implement the datetime module to begin with ;-) ).

EDIT - what a date "means"

I want to push back a bit on @abamert's "A date is an interval in time. It's not 00:00:00 on that day, it's the entire day." You're certainly free to think of it that way, but there was no such intent. I wrote almost all of the original datetime module (both the Python and C versions), working with the primary module designers: Guido van Rossum and Jim Fulton.

Guido was very keen on the notion of "naive" dates and times, an everyday "common sense" notion of dates and times that simply ignores all the tedious subtleties geeks like to obsess over ;-) (like historical time zone - and even calendar - adjustments, and "leap seconds" of no actual use to anyone save astronomers). To him, the best way to know what a date was intended to mean is to ask a 12-year-old. And their answer doesn't matter. If they think date(2014, 1, 9) means "the entire day", fine. If they like to think of it as the stroke of midnight at the start of the day, also fine. Ditto midnight at the end of the day, or noon, or 3pm nap time, or different times on different days, or no time at all attached ... those distinctions are all in your head so far as date is concerned. date doesn't encourage or discourage any of them.

Now a geek may object "but if I think of date(2014, 1, 9) as being noon and you think of date(2014, 1, 10) as being 3pm, subtracting them returns a wrong answer!". Yawn. Ask a 12-year-old: it's obvious that, for naive dates, the difference is exactly 1 (naive) day.

There's nothing here suggesting that any particular person or application "should" find that useful. Many applications do find it useful. If yours isn't one of them, don't use it.

All in all, the only major regret I have about datetime is that tzinfo objects have no reliable way to distinguish between "standard" and "daylight" times during the ambiguous transition hours. Guido's sense of frugality was offended (overly so, in my opinion) by that a C struct tm "wasted" an entire int (tm_isdst) for this 1 bit of information only needed to disambiguate transition times. It's not a coincidence that most geographical areas that switch between "daylight" and "standard" times make these transitions when most people are asleep, so for almost all practical purposes the ambiguities are invisible ("what do you mean, 2:10am? is that the first time the clock read 2:10am, or the second time after we set the clock back an hour from 3am to 2am again?"). But for those few who really do care, living without that bit remains a royal pain :-(