Django

Code

Ticket #7201 (closed: fixed)

Opened 2 years ago

Last modified 2 years ago

timeuntil filter misbehaves if my datetime has a timezone

Reported by: terry@weissman.org Assigned to: jcarbaugh
Milestone: 1.0 Component: Template system
Version: SVN Keywords: timeuntil, timesince
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Looking in the code, I see that django.utils.timesince carefully tries to compute "now" using an appropriate timezone if you call timesince() with now=Null. However, if you call the timeuntil() routine in that module, or if you use django.template.defaultfilters.timeuntil(), then it computes now using no timezone at all. If the datetime you pass into timeuntil has a timezone set, then the result you get is several hours off.

Attachments

7201.diff (8.0 kB) - added by jcarbaugh on 08/01/08 15:34:40.
Fixes timezone errors in timeuntil and timesince. Includes tests and documentation updates.
7201.2.diff (7.3 kB) - added by jcarbaugh on 08/03/08 22:05:57.
Modification of original patch to not assume timezone when none exists.
7201.3.diff (7.8 kB) - added by jcarbaugh on 08/16/08 21:22:59.
This patch is the same as 7201.2.diff with an added change to AUTHORS per Malcolm's request.
7201.4.diff (7.9 kB) - added by jcarbaugh on 08/25/08 16:50:13.
Updated to work with changes introduced in [8535]

Change History

07/16/08 02:51:00 changed by serialx

  • needs_better_patch changed.
  • component changed from Uncategorized to Template system.
  • needs_tests changed.
  • milestone set to 1.0.
  • keywords set to timeuntil, timesince.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.

Seems to be a clear bug.

07/18/08 19:14:02 changed by leahculver

  • owner changed from nobody to leahculver.
  • status changed from new to assigned.

07/18/08 20:40:06 changed by leahculver

  • owner deleted.
  • status changed from assigned to new.

08/01/08 09:38:40 changed by jcarbaugh

  • owner set to jcarbaugh.
  • status changed from new to assigned.

08/01/08 14:48:13 changed by jcarbaugh

  • has_patch set to 1.

Prior to this patch, the timesince(d, now=None) method would overwrite the timezone of the now argument if the d argument had tzinfo. This would cause the time difference to be calculated incorrectly. Additionally, if d did not have tzinfo, the tzinfo of now would be reset to None. In this case, the patched version will give the d argument the tzinfo of now to keep the behavior the same for both arguments.

This patch raises the issue of whether the timesince method should assume a timezone if one argument has tzinfo and the other does not. Default Python behavior is to raise a TypeError? when operating on offset-naive and offset-aware datetimes. I am opening another ticket to address the issue of how this should be handled. Allowing an error to be raised when comparing timezone and non-timezone arguments will be a backwards incompatible change.

08/01/08 14:58:07 changed by jcarbaugh

Ticket #8080 has been created to address the behavior of timesince and timeuntil.

08/01/08 15:34:40 changed by jcarbaugh

  • attachment 7201.diff added.

Fixes timezone errors in timeuntil and timesince. Includes tests and documentation updates.

08/03/08 22:05:57 changed by jcarbaugh

  • attachment 7201.2.diff added.

Modification of original patch to not assume timezone when none exists.

08/03/08 22:15:42 changed by jcarbaugh

After thinking about the patch over the weekend and trying a few extra tests, I decided that the original patch did not adequately address the issue. The real bug in the code was not that a timezone was being overwritten, but that a timezone was assumed at all. Even with the bug fixed with the original patch, unexpected output still existed when a timezone was incorrectly assumed.

The current patch fixes the initial bug and any other instance where datetime arguments contain tzinfo. If two arguments are passed, one with tzinfo and one without, the filter will return an empty string as other filters do on TypeError? or ValueError?.

This patch did not break any previous tests, but may be backwards incompatible in cases where offset-naive and offset-aware datetimes are used as arguments.

I've closed #8080 that I opened earlier as this patch resolves that issue.

08/16/08 19:35:25 changed by mtredinnick

I think you're logic is pretty sound in the revised patch. I think we can wear the backwards incompatibility, since I'd argue that if you're relying on the current behaviour, your results are already wrong.

Can you include a patch for the AUTHORS file as part of this? This isn't a trivial amount of effort to have worked it all out. We should immortalise your efforts.

08/16/08 21:22:59 changed by jcarbaugh

  • attachment 7201.3.diff added.

This patch is the same as 7201.2.diff with an added change to AUTHORS per Malcolm's request.

08/16/08 21:23:46 changed by jcarbaugh

Thanks for reviewing the patch, Malcolm.

08/25/08 16:50:13 changed by jcarbaugh

  • attachment 7201.4.diff added.

Updated to work with changes introduced in [8535]

08/26/08 03:08:56 changed by mtredinnick

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [8579]) Fixed #7201 -- Fixed the timeuntil filter to work correctly with timezone-aware times. Patch from Jeremy Carbaugh.

This is backwards incompatible in the sense that previously, if you tried to compare timezone-aware and timezone-naive values, you got an incorrect result. Now you get an empty string. So your previously incorrect code returns a different incorrect result.

Add/Change #7201 (timeuntil filter misbehaves if my datetime has a timezone)




Change Properties
Action