Why are timezone aware and naive datetimes not distinct classes?

[Chris Angelico]

On Sat, Mar 9, 2013 at 8:33 AM, Nobody <nobody at nowhere.com> wrote:
> On Fri, 08 Mar 2013 13:41:27 -0500, Roy Smith wrote:
>
>> So, the question is, WHY aren't aware and naive datetimes separate
>> classes?  They share many attributes and methods, but not all.
>
> They share all attributes and methods.
>
> You could just as well ask why positive and negative floats aren't
> separate classes (based upon the fact that e.g. math.sqrt() and math.log()
> raise domain errors for negative floats).
>
> Just because certain operations aren't defined for all values (or all
> combinations of values), that doesn't make the values where those
> operations aren't defined into a distinct type.

They represent different things, though. A naive datetime is kinda
like an integer - an abstract thing that has meaning only as the
programmer gives it meaning; an aware datetime unambiguously
represents an instant in time. SQL has completely different data types
for "TIMESTAMP WITHOUT TIME ZONE" and "TIMESTAMP WITH TIME ZONE".

As I see it, a naive datetime simply does not have a timezone. The
fact that it may have an attribute that's set to None doesn't mean
that it "shares all attributes" with aware datetimes; if they were
implemented completely separately (without even a common base class),
the most obvious difference would be the complete absence of timezone
attribute on the naive type.

Conceptually, Roy's notion of a common base class makes good sense.
But I can't speak for the Python datetime module as I've hardly used
it; there may be practical considerations that mean the current model
works better. All I can say is, there's definitely more difference
between aware and naive datetimes than there is between positive and
negative floats.

ChrisA