[Datetime-SIG] Another round on error-checking

Carl Meyer carl at oddbird.net
Wed Sep 2 22:26:10 CEST 2015

On 09/02/2015 01:59 PM, Tim Peters wrote:
> Yes, but I believe it's worse:  that it's impossible for PEP 495 to be
> wholly backward compatible regardless of whether intrazone comparison
> ignores `fold`.  It's not just "stare at one line of code" that counts
> for compatibility, breaking former invariants also counts.  Like
> Stewart mentioned just before, anyone in their right mind ;-)
> _implicitly_ assumed all along that
>     x == y
> implies
>     x.utctimetuple() == y.utctimetuple()
> and, indeed,
>     x.astimezone(SOMETZINFO) == y.astimezone(SOMETZINFO)
> too for any value of SOMETZINFO.
> PEP 495's original form breaks those (among others) - it's not
> credible to claim that no existing code could possibly be relying on
> those (or relying on total datetime ordering, etc).  That may not be
> reflected in any single line of code, but only in what code _didn't_
> do to worm around "a problem" it reasonably - perhaps not even
> consciously - assumed could never happen.
> The only way I see to be wholly backward compatible is to default to
> fold = -1, [...]
> In naive time, `fold=1` is simply senseless.  It "should be" ignored
> in naive time.  But there is no wall between "naive time" and
> "timeline time" in datetime's design - indeed, there is no _explicit_
> way to say which you have in mind.  Something has to give, because an
> aware datetime can be _viewed_ as being either in naive time or as in
> timeline time.  That's in the programmer's head.  Since fold=1 makes
> no sense in naive time, the sanest thing is to take it as meaning the
> datetime can _only_ be viewed as being in timeline time.  We already
> know that solves a world of problems.

Totally in agreement with everything above.

To summarize: trying to disambiguate folds leads to contradiction if the
implementation doesn't fully accept a "timeline" view of tz-aware
datetimes, because in a "naive" view, the two overlapping times in a
fold are the _same time_. The very idea of disambiguation itself is a
"timeline view" concept; it's not consistent with naive time.

> But it will create others.

Can we enumerate the specific problems this would create?

Let's hypothesize the following proposal:

* As discussed in earlier threads, datetime is taught to respect a new
`strict` flag on tzinfo objects, treating aware datetimes as fully in
"timeline time," including for arithmetic, (only) if it is set. If it is
not set, no behavior changes from what we have today.

* The `fold` flag is respected in any way (and ever set to anything
other than -1 by built-in methods) _only_ if the attached tzinfo has

Now what problems would this cause?

* Backwards compatibility is not a problem. There are no tzinfo classes
currently in existence with `strict=True`.

* All of PEP 495's problems with hashes, equality, and ordering that
have been discussed in this thread are solved; `fold` is entirely unused
with non-strict tzinfo, and entirely consistent with strict tzinfo.

* Ability to work with timezone-annotated datetimes (I can't say
"timezone-aware" with a straight face for datetimes that operate in
naive time) in naive time, which is a use case that some people have, is
preserved; just use a tzinfo with `strict=False`.

* Working with a "timeline view" of tz-aware datetimes (which is also a
valid use case that some people have) becomes much simpler than it is
today; much simpler even than with pytz.

It looks like all wins to me.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150902/58efc1c6/attachment.sig>

More information about the Datetime-SIG mailing list