where is >> a bug in the following calculation? >> >> >>> print(lt) >> 2015-03-07 12:00:00-05:00 >> >>> lt += timedelta(1) >> >>> print(lt) >> 2015-03-08 12:00:00-05:00 > > Well, let's say I live in New York, so all winter long I've been seeing > things like "2015-01-17 9:37:51-05:00", etc. and then the time switches in > March and I fail to notice that the "-05:00" is still "-05:00" and not > "-04:00" -- especially since my watch, clock, smart phone, etc., don't > display the offset -- well, something bad will happen:
If you expect to see local time, you probably aren't looking at ISO timestamps. > exactly what depends on what the user was expecting when adding a day. Not really -- that distinction is about Duration vs Period arithmetic. This is about the fact that a tzinfo object that represents an offset simply has no idea about DST transitions -- it CAN'T do the period arithmetic some people want. In your use case -- don't use an offset. Period, end of story. If you want Period arithmetic, use full featured tzinfo objects. ( and dateutils ). And don't expect to be able to round-trip via an ISO 8601 string. -Chris _______________________________________________ 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/
