[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
alexander.belopolsky at gmail.com
Wed Aug 19 18:15:55 CEST 2015
On Wed, Aug 19, 2015 at 11:55 AM, Guido van Rossum <guido at python.org> wrote:
>> > Isn't it so that you could get timeline arithmetic today by giving each
>> > datetime object a different tzinfo object?
>> Yes. In fact, this is exactly how pytz works around it. With pytz, every
>> tzinfo _instance_ is a fixed-offset instance (e.g. there are distinct
>> tzinfo instances for EST and EDT). This means if you do arithmetic using
>> an EST datetime and an EDT datetime, you'll get (timeline-arithmetic)
>> correct results. The downside of this approach (though once you get used
>> to it it's at least predictable and explicit) is that if you do
>> arithmetic using e.g. an EST datetime and a timedelta, you'll always end
>> up with an EST result, even if the result crossed a transition to EDT
>> (so it's sort of an "imaginary extension of EST"), and you have to
>> remember to use a pytz-specific "normalize()" API, which will adjust the
>> datetime by an hour and switch the tzinfo from EST to EDT.
> That does not sound like what I was proposing (as a hack) -- it simply
> exchanges one bug for another.
No, it is not a bug. Just a slight inconvenience for the programmer.
Here is how you do strict timeline arithmetics in local time using
>>> t = datetime(2015, 3, 7, 17, tzinfo=timezone.utc)
>>> lt = t.astimezone()
Good - we've got an aware local time.
>>> lt += timedelta(1)
This is not a wrong answer. "2015-03-08 12:00:00-05:00" is indeed 24
hours after "2015-03-07 12:00:00-05:00". The only problem is that
people in the US/Eastern timezone don't spell it that way: they
already use summer time (-04:00) on 2015-03-08. However, fixing this
is one method call away:
All the "timeline arithmetic" gets you is the ability to write correct
code without that one extra call.
More information about the Datetime-SIG