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

Stuart Bishop stuart at stuartbishop.net
Tue Aug 25 15:30:50 CEST 2015

There is a point I'd like to clarify in the current PEP:

Strict Invalid Time Checking

Another suggestion was to use first=-1 or first=None to indicate that
the program truly has no means to deal with the folds and gaps and
dt.utcoffset() should raise an error whenever dt represents an
ambiguous or missing local time.

The main problem with this proposal, is that dt.utcoffset() is used
internally in situations where raising an error is not an option: for
example, in dictionary lookups or list/set membership checks. So
strict gap/fold checking behavior would need to be controlled by a
separate flag, say dt.utcoffset(raise_on_gap=True,
raise_on_fold=False) .

As mentioned elsewhere, pytz requires strict checking to remain
backwards compatible. The description above does not match the desired
behaviour though. 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.

This would require the first argument to be available in all the
methods that can construct datetime instances, including things not
mentioned in the PEP like dt.astimezone() (Where I think it might be
using the first flag from the original dt instance, rather than
allowing the user to specify which side of the fold in the target

Stuart Bishop <stuart at stuartbishop.net>

More information about the Datetime-SIG mailing list