﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
25352	django.views.generic.dates.WeekArchiveView use of _date_from_string results on off-by-one weeks handling	Didier Raboud	nobody	"While trying to use WeekArchiveView to display objects in given weeks (and navigate within weeks), I've found that the data would be displayed off by one week, which makes it very confusing to use.

I think the problem start there:
https://github.com/django/django/blob/master/django/views/generic/dates.py#L551 :

{{{
        date = _date_from_string(year, self.get_year_format(),
                                 week_start, '%w',
                                 week, week_format)

        since = self._make_date_lookup_arg(date)
        until = self._make_date_lookup_arg(self._get_next_week(date))
}}}

`date` is then used as `since`, which should be the start of the '''current''' week, while `_date_from_string` outputs the day starting the next week (format in use being '%w').

{{{
>>> from django.utils import timezone
>>> now = timezone.datetime.now()
>>> now.strftime('%W')
'35'
>>> now.isocalendar()[1]
36
>>> from django.views.generic.dates import _date_from_string
>>> _date_from_string('2015', '%Y', '1', '%w', '35', '%W')
datetime.date(2015, 8, 31)
}}}

Actually, I'm not sure where the bug lays, but seeing `.isocalendar()[1]` differ from `.strftime('%W')` is certainly weird. So far, it seems to me to be the cause for my `previous_week` and `next_week`-based buttons to have off-by-one errors. Is there any reason for `.strftime('%W')`  https://github.com/django/django/blob/master/django/utils/dateformat.py#L300 not to use `.isocalendar()` ?

What am I overlooking, or doing wrong?"	Bug	closed	Generic views	1.8	Normal	needsinfo			Unreviewed	0	0	0	0	0	0
