[ijs] > > But I agree, PEP 495 is a small and straightforward step in the > > right direction. Though it's not looking like the bikeshed is going > > to get painted my color. :)
[Tim] > What if we renamed "fold" to "ijs"? We aim to please ;-) Heh. I argued that pandas should call it "ambiguous" and allow it the values True | False | 'NaT' | 'raise' | 'infer', where the boolean values had the same sense as if the flag were "is_dst" or "first" and 'NaT' and 'infer' were important for the vectorized case. And I convinced them, and they painted the bikeshed my color, and now I have doubts and wonder whether the flag should simply be called "is_dst" since that's what everyone else calls it (so that must be how they think of it, right?) and accompanied by a stern corner-case warning in the docs. Which is to say that I think it's important that the flag's name be grokkable. "is_dst" is grokkable. "first" is grokkable, once you get past the point of "first what?". "fold" is not grokkable. It's also not discoverable, which is also a problem for "first"-- the name of the field doesn't tell you what problem it solves. Nobody is going to be confused about what "is_dst" means (which is great until you get to a corner case where it doesn't mean that). So I'm torn between "is_dst" and "first", but I really don't like "fold". And that's all I have to say about that. > > ... > > I assume pytz is committed for backward compatibility to timeline > > arithmetic for datetime subtraction, which means it can't afford to > > change its "one tz instance per offset" design as long as datetime > > arithmetic ignores the time zone when it's identical. > > For backward compatibility, and for consistency with classic datetime > + timedelta addition, the default datetime subtraction won't change. > They both have to use the same kind of arithmetic for the obvious > identities to hold. But nothing in PEP 495 precludes offering > optional timeline arithmetic later - arithmetic just isn't in 495's > scope. > > > There's no hook for pytz to hang its behavior on, and PEP 495 > > doesn't give it one. > > I don't grasp why people keep bringing up issues PEP 495 never > intended to address when talking _about_ 495. PEP 495 is _not_ a > proposed substitute for PEP 431, and Alexander never claimed it was. > It's a different path entirely, prudently (IMO) proposing a relatively > small change to get things moving in a useful direction. Even if all > related activity stops with 495, fixing conversions alone is worth > some effort. Not even appealing to "naive time" can really excuse > screwing up conversions _between_ naive times ;-) I brought it up because I'm looking at PEP 495 through the lens of "how much simpler does this allow pytz's API to become?" Support for timeline arithmetic is a major constraint on pytz's design, and it could hamper that module's ability to make use of the gains from PEP 495-- in which case I would argue that the scope of the PEP should be expanded at least enough to permit pytz to partake. I initially thought this would be necessary, but then reread the relevant parts of _datetimemodule.c and came to the conclusion that it's not. But I admit I did not motivate the connection in my post. > > On the upside, it does look like there's a way to foil the dreaded > > self check in datetime_astimezone and make dt.astimezone(tz) > > work as intended. > > I can pretty much guarantee it always worked as intended ;-) As Stuart intended, when tz is a pytz.DstTzInfo object and in the corner case that dt is a non-normalized datetime in the same time zone (i.e., dt.tzinfo.utcoffset() returns the wrong offset). Jeez, how could that not be obvious? ;D > If you > mean that 495 will make it work when dt is naive, that's marginal to > me. Treating a naive datetime as being a local time is as senseless > as treating it as a UTC time - it's arbitrary. I'd rather > datetime.timezone grew a name for a tzinfo representing the system > timezone, so "local time" became as easy to spell explicitly (when > desired) as "utc" has become already. But that's out of scope for 495 > too. That's not what I mean; I agree with you here. ijs _______________________________________________ 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/
