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

Tim Peters tim.peters at gmail.com
Tue Aug 25 05:55:59 CEST 2015


[Tim]
>> ...
>> In any case, there is no active PEP at the moment proposing to add any
>> new timezone implementations to Python.  One step at a time.

[ijs]
> PEP 431 did.

Hence my "active" PEP.  Lennart withdrew 431.

> 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. :)

What if we renamed "fold" to "ijs"?  We aim to please ;-)


> ...
> 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 ;-)


> 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 ;-)  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.


More information about the Datetime-SIG mailing list