[Datetime-SIG] Another round on error-checking
carl at oddbird.net
Thu Sep 3 01:01:32 CEST 2015
> [Carl Meyer <carl at oddbird.net>]
>> 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.
> Fun, isn't it?
I think the number of people for whom this qualifies as "fun" approaches
the number of people who have ever implemented a tzinfo ;)
>>> But it will create others.
>> Can we enumerate the specific problems this would create?
> That use of "we" appears to mean "anyone but Carl" ;-)
Right - I mis-read the referent of "it" above. You were talking about
the proposal to make fold=1 (only) force "timeline view". I understand
the problems that causes.
I mis-read and thought you were suggesting the possibility of "use
timeline view always," and saying _that_ "creates other problems." So I
was trying to think of what problems those would be, and not thinking of
>> 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.
> Why conflate this with arithmetic? It's. e.g., quite possible someone
> wants correct interzone conversion in all cases without getting sucked
> into way-slower arithmetic too.
One reason to conflate with arithmetic is to limit the number of mental
models people have to comprehend. If we conflate, there would be two
models: "naive model" and "timeline model", and the choice between them
would be controlled by one flag.
I think that's already more than enough complexity for most people, but
it's simplicity itself compared to the possibility that we could end up
with three models: "naive model", "timeline model for conversions but
still naive for arithmetic", and "timeline model".
ISTM the second is too confusing and inconsistent in its view of the
world to be featured as a primary mode; if someone really needs it, it'd
be easy enough to write functions to do fast naive arithmetic on
strict-aware datetimes (strip the tzinfo, then add it back). (The
write-your-own-function argument can go both ways! ;)
> For the purposes of 495, I'm going to
> pretend that using fold is controlled by the presence of a new tzinfo
> __fold__ attribute (we can't use a flag, because _existing_ tzinfos
> don't already have it).
As an API choice I think "boolean flag with default if not present" is
preferable to "mere existence of an attribute causes a switch in
behavior, regardless of its value." But this is definitely a low-order
>> * 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
> Since there's now a way to spell "ignore fold" versus "respect fold",
> there's no longer any point to fold < 0. "Ignore fold" is now the
> default, and "respect fold" has to be explicitly requested.
> For simplicity, any function that knows how to set fold correctly
> should be _allowed_ to do so regardless.
Yes, good point.
>> * 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.
> There are still questions, like, e.g., what
> fold_aware_datetime + timedelta
> should do when fold=1, but only in my variation of what you proposed.
> You proposed mixing "pay attention to fold" with "timeline
> arithmetic", which leaves no choice.
Yes. Point for my proposal :-)
The fact that that even has to be a question illustrates how
"timeline-mode conversions with fold disambiguation, but naive model for
arithmetic" remains a problematic split-brain model that leads to
> I'm still to keen to push timeline arithmetic off to a later PEP. It
> doesn't have to be addressed to solve 495's problems.
I think you've convincingly demonstrated in this thread that
conversions, equality, comparisons, and arithmetic _are_ all
fundamentally linked. If you try to cut them apart and handle some with
a timeline model and some with a naive model, you'll have to violate a
reasonably-expected invariant _somewhere_.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG