[Datetime-SIG] Conversion vs arithmetic (was Re: Is EDT a timezone? Was: PEP-0500)

ISAAC J SCHWABACHER ischwabacher at wisc.edu
Tue Aug 25 20:37:10 CEST 2015


[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



More information about the Datetime-SIG mailing list