consistent use of tzinfo.normalize()
|Reported by:||Christian Boos||Owned by:||Jun Omae|
|Severity:||normal||Keywords:||datetime pytz timezone|
Fix of datetime arithmetic across DST boundaries with pytz timezone
As a follow-up to #10863, I had a closer look to our use of
According to http://pytz.sourceforge.net/#localized-times-and-date-arithmetic, using
normalize() is necessary after having performed arithmetic on localized
datetime, and when switching timezones (
t.astimezone(tz), except when
There are several places in
trac/util/datefmt.py where we use
astimezone() or do arithmetic without wrapping this in
There's also a place in
to_datetime() where we use
normalize(localize()), which seems unnecessary.
Beyond datefmt.py, there are other places where we do arithmetic on localized dates, we should handle them as well when the end result will likely end up being displayed (e.g. a milestone's
duedate). It could be left unchanged when the computed datetime will be used for its "absolute" value (e.g.
start in the TimelineModule).