On Wed, Aug 19, 2015 at 8:38 AM, Carl Meyer <[email protected]> wrote:
> On 08/19/2015 09:30 AM, Guido van Rossum wrote: > > Yes, that's the right way to define it (and PEPs should primarily > > concern themselves with crisp definitions). > > > > 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. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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/
