On 08/25/2015 05:16 PM, Alexander Belopolsky wrote:

Here is an outline of a "Strict Invalid Time Checking" that might work: the values of datetime.fold attribute will be restricted to 0 and 1, but the datetime constructor will accept None as a possible value of the fold argument. The datetime constructor that receives fold=None will set self.fold both ways and call self.tzinfo.utcoffset(self) twice before returning the constructed instance. If the values returned by the two utcoffset() calls match - an instance with self.fold=0 will be returned, if not - they will be compared and an appropriate error returned.

This design seems workable, but immediately raises a question: shouldn't datetime constructor get the strict=False argument instead of encoding it in the third value of fold?

And if we want to have datetime(..., strict=True), why not just have strict_datetime(...) function in your toolkit or on PyPI? Not every 8-line function need to be in the standard library.

We can discuss this and other questions if someone decides to champion a Strict Invalid Time Checking PEP after PEP 495 is in-place.

Works for me. You've convinced me that it's a subtle enough problem to deserve its own PEP. And since it would likely involve adding either a new argument to some methods/constructors, or a new (invalid under PEP 495) value to the disambiguation flag, there's no sense in which it needs to be done at the same time; PEP 495 won't restrict future options. Carl