[Datetime-SIG] PEP-495 - Strict Invalid Time Checking
carl at oddbird.net
Tue Aug 25 23:44:54 CEST 2015
On 08/25/2015 03:36 PM, Alexander Belopolsky wrote:
> On Tue, Aug 25, 2015 at 5:28 PM, Carl Meyer <carl at oddbird.net
> <mailto:carl at 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
This is a good question. I can see two defensible choices:
1) Sure, go ahead and propagate, and document it. Anyone choosing to use
`fold=None` is responsible to ensure their aware datetimes are valid
(i.e. immediately on constructing/combining/localizing them) before
doing anything else, or else be prepared to catch InvalidTimeError
pretty much anywhere else. This would be entirely fine with me.
2) In the specific case of `__eq__`, catch it and only consider the two
datetimes equal if they both raised the same invalidity exception.
But I think while (2) is tenable for `__eq__`, it doesn't have such a
neat resolution for inequality comparisons and probably other cases
either, so (1) is probably best.
P.S. There's a very strong temptation to break out the Zen of Python
here, as it rarely applies so directly: "In the face of ambiguity,
refuse the temptation to guess." And the discussion here isn't even
contemplating following the Zen by default, only giving users a
convenient option to follow the Zen! ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG