Opened 13 years ago
Closed 13 years ago
#17829 closed Bug (wontfix)
Admin date filter's "Past 7 days" actually returns past 8 days.
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.4-beta-1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Essentially the problem is analogous to
end = 10 start = end - 7 qs.filter(f__gte=start, f__lte=end) # this will allow 8 numbers not 7 (namely: [3,4,5,6,7,8,9,10])
I think this is fairly obvious (and easy to fix), but I an explain more if needed.
Change History (6)
comment:1 by , 13 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Yes, I thought about this after submitting the ticket. Though, I think this is still an issue for DateTimeFields. Basically, I think what is expected, is that no future dates are selected (if it can be helped). I don't really care about this being fixed, but I think it is still a bug.
comment:3 by , 13 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → Design decision needed |
comment:4 by , 13 years ago
To be honest, I don't care much either. Let's keep it as DDN to get more opinions...
comment:5 by , 13 years ago
For a end-user, "past 7 days" essentialy means "show me everything since, and including, last <week day>". You don't do the math using hours, you compute with whole days. I believe the current behaviour is the most expected behaviour, or at least the less surprising one.
comment:6 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Yeah, I've just re-implemented this feature in the context of another ticket and I felt like hcarvalhoalves.
list_filter
on a DateTimeField is mostly useful if applied to a field that stores a creation or modification date.It's Monday, 8am. Do you expect to see the updates of last Monday? Probably yes.
In this case, the current code shows 7,33 days worth of data in this case (assuming you have no dates in the future). Your "easy fix" would show 6,33 days instead. I'm not convinced this would be significantly more correct.
We'd need a good reason, good enough to warrant breaking backwards compatibility, to change this.