Opened 8 years ago
Closed 8 years ago
#27637 closed Bug (fixed)
timeuntil, timesince breaks in leap year edge case
| Reported by: | Mariusz Felisiak | Owned by: | vinay karanam |
|---|---|---|---|
| Component: | Utilities | Version: | 1.9 |
| Severity: | Release blocker | Keywords: | timeuntil timesince |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
django.utils.timesince.timesince and django.utils.timesince.timeuntil breaks in leap year edge case. Bug appeared after 6700c909358d2ff9ff96f28dbc549906d8d32206. If we take two dates from different years where one of them is leap and leap day is not between days gap then timeuntil returns incorrect result e.g.
timeuntil(datetime.date(2016, 12, 25), datetime.date(2017, 1, 1))
returns 1 week, 1 day != 1 week.
Attachments (1)
Change History (15)
by , 8 years ago
| Attachment: | 27637.diff added |
|---|
comment:1 by , 8 years ago
| Severity: | Normal → Release blocker |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Version: | master → 1.9 |
comment:6 by , 8 years ago
| Has patch: | unset |
|---|---|
| Resolution: | fixed |
| Status: | closed → new |
There's still a regression on the last day of a leap year (I think). Here's the failure:
======================================================================
FAIL [0.001s]: test_date_objects (utils_tests.test_timesince.TimesinceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jenkins/workspace/pull-requests-trusty/database/sqlite3/label/trusty-pr/python/python2.7/tests/utils_tests/test_timesince.py", line 98, in test_date_objects
self.assertEqual(timesince(today + self.oneday), '0\xa0minutes')
AssertionError: u'9\xa0hours, 56\xa0minutes' != u'0\xa0minutes'
- 9\xa0hours, 56\xa0minutes
+ 0\xa0minutes
comment:7 by , 8 years ago
| Status: | new → assigned |
|---|
comment:9 by , 8 years ago
I think that you shouldn't reassigned ticket if someone else is working on it.
comment:10 by , 8 years ago
Sorry for that.
I just wanted you to be aware that I have already raised a PR for the fix.
I waited for an hour after raising the PR to modify the ticket.
comment:14 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Marking as a release blocker because there are
timeuntiltest failures that must be fixed on the 1.10 and 1.9 branches, whether that's by fixing the regression or by fixing the tests so they're not dependent on the day in which they run. The latter is probably better for 1.9.x since it's only receiving security fixes at this time.