Re: [Datetime-SIG] PEP-495 - Strict Invalid Time Checking
On 08/25/2015 03:22 PM, Alexander Belopolsky wrote:
On Tue, Aug 25, 2015 at 5:04 PM, Carl Meyer <carl@oddbird.net <mailto:carl@oddbird.net>> wrote:
I can't imagine how raising an exception on invalid times only if a non-default sentinel value is given for a flag that is _new in PEP 495_ could possibly break 4000 lines of existing datetime tests.
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.
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). Carl
On Tue, Aug 25, 2015 at 5:28 PM, Carl Meyer <carl@oddbird.net> wrote:
My answer is "only in those same locations where the fold attribute would otherwise be checked in order to resolve an ambiguity."
This includes utcoffset() which is used in datetime.__eq__. What should __eq__ do if utcoffset() raises AmbiguousTimeError? Unpatched, it will propagate the exception resulting in for example x in [y, x, x, x] raising an error whenever y happened to be fold=-1 ambiguous. Is your code prepared to handle AmbiguousTimeError whenever you search for a date in a list? Does it check for fold != -1 before adding a date to a list?
[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.
participants (3)
-
Alexander Belopolsky -
Carl Meyer -
Tim Peters