[Datetime-SIG] Another round on error-checking

[Tim Peters]

[Carl Meyer <carl at oddbird.net>]
> ...
> To summarize: trying to disambiguate folds leads to contradiction if the
> implementation doesn't fully accept a "timeline" view of tz-aware
> datetimes, because in a "naive" view, the two overlapping times in a
> fold are the _same time_. The very idea of disambiguation itself is a
> "timeline view" concept; it's not consistent with naive time.

Fun, isn't it?

[Tim]
>> But it will create others.

> Can we enumerate the specific problems this would create?

That use of "we" appears to mean "anyone but Carl" ;-)  The problems
it could create depend on the contexts in which the PEP says fold
would not be ignored.  While nobody has mentioned it, it _could_ be
that someone working in naive time would be annoyed even by
dt.utcoffset() returning different results depending on `fold`.  While
it's a goal of the PEP to _make_ them differ in some cases, that in
itself isn't wholly backward compatible in all conceivable cases.
Then why would the use a 495-compliant tzinfo to begin with?  Because
they'er a user, and they don't understand any of this stuff ;-)


> Let's hypothesize the following proposal:
>
> * As discussed in earlier threads, datetime is taught to respect a new
> `strict` flag on tzinfo objects, treating aware datetimes as fully in
> "timeline time," including for arithmetic, (only) if it is set. If it is
> not set, no behavior changes from what we have today.

Why conflate this with arithmetic?  It's. e.g., quite possible someone
wants correct interzone conversion in all cases without getting sucked
into way-slower arithmetic too.  For the purposes of 495, I'm going to
pretend that using fold is controlled by the presence of a new tzinfo
__fold__ attribute (we can't use a flag, because _existing_ tzinfos
don't already have it).

Arithmetic is a different issue.  Presumably a `strict` tzinfo would
be required to say "fold-aware" too, but also say more than just that.


> * The `fold` flag is respected in any way (and ever set to anything
> other than -1 by built-in methods) _only_ if the attached tzinfo has
> `strict=True`.

Since there's now a way to spell "ignore fold" versus "respect fold",
there's no longer any point to fold < 0.  "Ignore fold" is now the
default, and "respect fold" has to be explicitly requested.

For simplicity, any function that knows how to set fold correctly
should be _allowed_ to do so regardless.


> Now what problems would this cause?
>
> * Backwards compatibility is not a problem. There are no tzinfo classes
> currently in existence with `strict=True`.

It does appear to be wholly backward compatible, and that would be great.


> * All of PEP 495's problems with hashes, equality, and ordering that
> have been discussed in this thread are solved; `fold` is entirely unused
> with non-strict tzinfo, and entirely consistent with strict tzinfo.

There are still questions, like, e.g., what

    fold_aware_datetime + timedelta

should do when fold=1, but only in my variation of what you proposed.
You proposed mixing "pay attention to fold" with "timeline
arithmetic", which leaves no choice.  Alex and I seem to disagree
about what to do when "only pay attention to fold" is meant instead.
I think it makes a difference now that they're explicitly asking to
respect fold - but I'm not yet sure _what_ difference it makes ;-)


> * Ability to work with timezone-annotated datetimes (I can't say
> "timezone-aware" with a straight face for datetimes that operate in
> naive time) in naive time, which is a use case that some people have, is
> preserved; just use a tzinfo with `strict=False`.

"timezone-annotated" is a winner!  LOL - what a frickin ' mess ;-)


> * Working with a "timeline view" of tz-aware datetimes (which is also a
> valid use case that some people have) becomes much simpler than it is
> today; much simpler even than with pytz.

I'm still to keen to push timeline arithmetic off to a later PEP.  It
doesn't have to be addressed to solve 495's problems.


> It looks like all wins to me.

Good food for thought.  Thanks!