Opened 12 years ago
Last modified 11 years ago
#10864 closed defect
consistent use of tzinfo.normalize() — at Initial Version
Reported by: | Christian Boos | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 0.12.5 |
Component: | general | Version: | |
Severity: | normal | Keywords: | datetime pytz timezone |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
As a follow-up to #10863, I had a closer look to our use of tz.normalize()
.
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 tz
is utc
).
There are several places in trac/util/datefmt.py
where we use astimezone()
or do arithmetic without wrapping this in normalize()
.
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).
adding calls to normalize where I think we should call it, removing it when it shouldn't be needed