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. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
