[Datetime-SIG] Clearing up terminology

[Tim Peters]

[Tim]
>> ....I personally would have preferred that "aware" datetime objects
>> use strict/timeline arithmetic instead, but it's not a big deal to me either
>> way.

[[ijs]
> I thought I understood what you were saying until now, but through
> this entire discussion I have been under the impression that you felt
> the exact opposite of that last sentence (except for the not being a
> big deal part).

Ah. but my "preferred" above is past tense.  That's how I felt at the
time - and would still feel if we were starting over from scratch.
Throughout the vast bulk of _this_ entire discussion we've been
talking about the present and foreseeable future (in which "starting
over from scratch" doesn't exist).  Now backward compatibility, and
explaining how & why it's possible to live happily enough with the
status quo,, are far more important than that one of Tim's mild
preferences was frustrated a dozen years ago ;-)


>> [explains that strict/timeline arithmetic _is_ currently done when
>>  subtracting or comparing two aware datetimes]

[[ijs]
> So once we have an is_dst bit, what will be the result of
>
> tz = timezone('America/Chicago')
> datetime(2013, 11, 3, 1, 30, tzinfo=tz, is_dst=True) - datetime(2013, 11, 3, 1, 0, tzinfo=tz, is_dst=False)
>
> ?

I assume you already know, so I too will leave it as an exercise for
the reader ;-)

> How can it be consistent with current behavior and be anything other
> than timedelta(0, 1800), even though the first time preceded the second?

The result will change.  The intended and documented behavior has
always been to follow "strict arithmetic" rules in this case.  So that
it currently doesn't is, and always has been, a bug.  Not a bug in
subtraction itself, it's a bug in .utcoffset(), which couldn't
possibly get all cases right before the is_dst flag was added.  The
instant utcoffset() is repaired, subtraction and comparison will be
too.

Of course it's possible that the change will break somebody's
currently working code.  But that's true of all bug fixes.  I _might_
care if anyone could convince me that it has any real chance of
breaking code except for some timezone wonk's collection of edge cases
peppered with

# EVIL PYTHON!!!  HAVE THEY NO SHAME!!!!!??????!!!!!!

 comments ;-)