[Datetime-SIG] Clearing up terminology

[ISAAC J SCHWABACHER]

[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 ;-)

And this is the first time you've mentioned that. :)

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

[ijs]
But only when the aware datetimes have different time zones! It's precisely because of this behavior that pytz has one fixed-offset DstTzInfo object for each offset attained over a time zone's history, so that two datetimes in the same time zone but with different offsets will have different tzinfo members and therefore be converted to UTC before being subtracted.  This also means that addition leaves the datetime with the same fixed offset DstTzInfo object, so that calls to .utcoffset() and .dst() return the wrong result until the datetime object is normalized, which can be accomplished either with tz.normalize(dt) or with dt.astimezone(tz), except that the second way doesn't work if tz is dt.tzinfo (as opposed to one of the other DstTzInfo objects corresponding to tz).  So anyone who is already using pytz is using timedeltas as durations anyway, it's just that they and Stuart Bishop have to jump through hoops to accomplish it.  Which, come to think of it, might mean that the backward compatibility problem is overrated-- the behavior could be changed for aware datetimes only, and .normalize() could be added as a no-op.

> > 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.

I'm not clear on how narrowly you mean "this case".  What about

tz = timezone('America/Chicago')
dt = datetime(2013, 11, 3, tzinfo=tz)
[[(dt.astimezone(timezone.utc) + timedelta(hours=n1)).astimezone(tz)
    - dt.astimezone(timezone.utc) + timedelta(hours=n2)).astimezone(tz) for n2 in range(5)] for n1 in range(5)]

?

> 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 ;-)

...I might have had some comments of that nature in my code until fairly recently.  Though they weren't as angry as the comments about getting pytz and dateutil.tz to interoperate.  Or the comments about the device that tried to store sub-second resolution data in Excel format (days since 1899-12-30)... to five decimal places.

ijs