[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[random832 at fastmail.com]

Oops, pressed the wrong reply button and it didn't include the datetime
list.

On Sat, Sep 12, 2015, at 14:53, Tim Peters wrote:
> > I was trying to find out how arithmetic on aware datetimes is
> > "supposed to" work, and tested with pytz. When I posted asking why
> > it behaves this way I was told that pytz doesn't behave correctly
> > according to the way the API was designed.
>
> You were told (by me) that its implementation of tzinfos was not the
> _intended_ way.  Which is another way of saying it was an
> unanticipated way.  "Correctly" is a whole different kind of judgment.
> pytz users who faithfully follow the docs seem happy with it.

My context is that I am working on an idea to include utc offsets in
datetime objects (or on a similar object in a new module), as an
alternative to something like a "fold" attribute. and since "classic
arithmetic" is apparently so important, I'm trying to figure out how
"classic arithmetic" _is actually supposed to work_ when adding a
timedelta to a time lands it on the opposite side of a transition (or in
the middle of a "spring forward" gap).

If there is a "fall back" transition tonight, then adding a day to a
time of 12 noon today could end up as:

12 noon tomorrow, offset still DST.
12 noon tomorrow, offset in standard time, 25 hours from now in real
time.
11 AM tomorrow, offset in standard time, 24 hours from now in real time

Which one of these is "classic arithmetic"? Pytz (if you don't
explicitly call a "normalize" function) results in something that looks
like the first. In one of the models I've thought of, you can get the
second by replacing the tzinfo again, or the third by doing astimezone,
but the first preserves "exactly 24 hours in the future" in both the UTC
moment and the naive interpretation by leaving the offset alone even if
it is an "unnatural" offset.

The second one above is what you get when you call normalize.

My question was whether there are any real implementations that work the
intended way. If there are not, maybe the intended semantics should go
by the wayside and be replaced by what pytz does.