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

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Aug 26 00:37:03 CEST 2015


On Tue, Aug 25, 2015 at 5:50 PM, Carl Meyer <carl at oddbird.net> wrote:
>
> >     This is a good question. I can see two defensible choices:
> >
> > Pick one and try to defend it.  In the face of ambiguity ...
>
> I already did that.
>
> "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."
>
> and earlier in (1), "This would be entirely fine with me."


Just wanted to be sure. :-)

So your proposal is:

[Carl Meyer]
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.
[/Carl Meyer]

I interpret this as allowing __new__, .replace(), combine(), etc. to create
ambiguous fold=None instances, but any operation with those - comparison,
arithmetics, set/dict insertion or retrieval, etc - may raise
AmbiguousTimeError.

I am not sure what I as a user of such datetimes am supposed to do to
"ensure [my] aware datetimes are valid," but your idea clearly differs from
that of Stuart


[Stuart Bishop]
 pytz users need to optionally have exceptions raised
when they try to construct an invalid or ambiguous datetime instance,
directly via __new__ or indirectly with something like  dt.replace().
If these methods are called with first=None, it will be passed through
to dt.utcoffset() and it may raise an exception. dt.utcoffset() will
only ever raise an exception when the user has explicitly requested
construction of a datetime with strict checking. It will never raise
an exception in normal operation, including arithmetic, and could not
cause problems in the situations you cite.
[/Stuart Bishop]

If you understand each other and can agree on the list of datetime methods
that need to be patched to support fold=None - please do so and present a
joint proposal.

Meanwhile, I would like everyone to realize that lossless conversion of
gaps and folds is a tiny corner case in the universe of uses that the
datetime module has.  The goal of PEP 495 is to allow such conversion
 while provably not creating problems for the mainstream uses.  If we allow
creation of fold=None instances, all programs that use the datetime module
will have to be analyzed for how they handle them.  In large projects, you
may not even know the person who wrote the code that produced datetime
instances that the function you write today will receive tomorrow.   So
your choices will be either to sprinkle your code with assert dt.fold is
not None statements and your documentation with the warnings that fold=None
datetime instances are not supported, or be prepared to handle an exception
each time you touch a datetime instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150825/d07d0e89/attachment-0001.html>


More information about the Datetime-SIG mailing list