[Tim] > [Carl Meyer <[email protected]>] >> ... >> 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 ;) > [Tim] >>> 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 any. [Carl] >> 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. [Tim] > 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 bit here. >> * 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 >> `strict=True`. > > 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 inconsistencies. [Tim] > 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_. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
