[Datetime-SIG] PEP-495 - Strict Invalid Time Checking

[Tim Peters]

[Alexander]
>> OK, so datetime module itself will never set fold=-1.   In the list
>> below, can you mark the methods that need to be patched to check the
>> fold attribute in your preferred design:
> ...
>> Please ask Isaac and Stuart to do the same.  Once you agree on a list,
>> let's continue this discussion.

[Carl]
> My answer is "only in those same locations where the fold attribute
> would otherwise be checked in order to resolve an ambiguity." That is, I
> wouldn't introduce any new checks: only and exactly where PEP 495 would
> otherwise make a guess based on the fold attribute should it raise an
> exception if the fold attribute is set to a "don't guess" sentinel (for
> which I'd prefer None to -1, since the latter invites confusion with
> tm_isdst).

[and more iterations in later messages]

This is going nowhere fast ;-)  Best I can tell, time errors in pytz
are pretty darn predictable, typically occurring (if at all)
immediately upon explicitly calling `localize()` with `is_dst=None`.
I'm sure there are other ways, but that seems to be the gist of it.
And pytz users like it.

But somehow, in trying to translate to a 495-workalike, pytz's
explicit, straightforward scheme has turned into spraying the logic
all over datetime internals, to possibly raise time errors from many
contexts by magic, and even in the absence of the user explicitly
asking for the check _at the time_ a time error may be raised.  I
think it's important to note that nobody has any experience with that.
So Alexander is right to be concerned about bloat, slowdowns,
vagueness, and/or unintended consequences in a far more magical scheme
nobody has actually used.

So far as I'm concerned, this whole issue is off the table for PEP
495.  It's trivial to write a "check for folds or gaps" function
_given_ 495-compliant tzinfos, although only trivial for the highly
informed ;-)  Big deal.  Show a function raising pytz-like exceptions
once in the docs, and nobody else has to figure it out (with the bonus
that they can alter it to do whatever they really want in oddball
cases).  If people are happy enough today explicitly calling a
function in pytz, they should be happy enough tomorrow explicitly
calling a function in Python.  Life won't change for pytz users, and
plain-Python users will have new possibilities.

If it's truly the case that this all _could_ be built in to Python in
a reasonably usable, wholly backward compatible, "magical" way, fine -
then another PEP can be proposed to add it.  While related, it's a
different feature.  It's unreasonable to delay PEP 495 for whistles it
doesn't _need_ to meet its goals (which are overwhelmingly about
supplying a fold/gap flag in a backward-compatible way, to fix the
_fundamental_ current impossibility of doing timezone conversions
correctly in all cases - anything beyond that is at best just "maybe
nice to have" _in the context of_ PEP 495).  So write another PEP,
write a prototype, and let people kick the tires to see how it
actually works out in practice.