WeekArchiveView seens to be zero based for week, instead of one based.

[RichardZimmerEschborn]

Django 2.2.6, Python 3.7.3, OS Debian 10.4

# urls.py
urlpatterns = [
    path('Event/', EventWeekArchiveView.as_view(), name='event_list'),
]

#models.py
class Event(models.Model):
    title = models.CharField(max_length=100),
    start = models.DateTimeField()

    def __str__(self):
        return '{} {}'.format(self.title, self.start.strftime('%a %d. %b %Y'))

# views.py
class EventWeekArchiveView(WeekArchiveView):
    template_name = 'event_archive_week.html'
    model = Event
    date_field = 'start'
    ordering = 'start'
    year = 2020
    week = 0
    week_format = "%W"
    # week_format = "%U"

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        print(context)
        return context

# event_archive_week.html
<h1>WEEK {{ week|date:"W" }}</h1>
<h2> object_list</h2>
<ul>
   {% for event in object_list %}
      <li>{{ event }} </li>
   {% endfor %}
</ul>
<h2> event_list</h2>
<ul>
   {% for event in event_list %}
      <li>{{ event }} </li>
   {% endfor %}
</ul>

​http://127.0.0.1:XXX/Event generates output for dates: Dec. 29. until Jan. 4. or Dec. 30. until Jan. 5. depending on week_format setting.

Calling week = 0 should not generate any output, instead it should generate an error (like it is done, when calling week = 54). The output generated should instead be for calling week = 1

The reverse works correct: The templatetag <h1>WEEK {{ week|date:"W" }}</h1> translates to: WEEK 1.
But only, when the week_format setting is as shown in class definition. This is OK, since the templatetag does support IsoWeek only.

---

While debugging this I found that the resultset is twice in the context. Once under the name object_list and a second time under the name event_list. For large querysets this seems to be wasting recources.

#output of print(context)
{'paginator': None, 'page_obj': None, 'is_paginated': False, 'object_list': <QuerySet [<Event: Happening Wed 01. Jan 2020>]>, 'event_list': <QuerySet [<Event: Happening Wed 01. Jan 2020>]>, 'date_list': None, 'week': datetime.date(2019, 12, 29), 'next_week': datetime.date(2020, 6, 7), 'previous_week': None, 'view': <belegung.views.EventKwView object at 0x7fddaba967b8>}

[Mariusz Felisiak]

It's documented that the week_format attribute is a strptime() format string used to parse the week number and in ​strptime() docs you can find:

• %U - Week number of the year (Sunday as the first day of the week) as a decimal number [00,53]. All days in a new year preceding the first Sunday are considered to be in week 0.
• %W - Week number of the year (Monday as the first day of the week) as a decimal number [00,53]. All days in a new year preceding the first Monday are considered to be in week 0.

[RichardZimmerEschborn]

Well, then the documentation is also wrong!

If I want to access the archive of the first week of a year, I call the link /year/1 and expect the data for this year and week number one. But what I get is this year and week number 2

Or the other way round, the user calls the web page /2020/24, but gets a page for 2020/25, which shows the data of the 25th week and has the title of the 25th week: Is this the expected result of an SEO friendly link?

Computers are supposed to work for users, not users work for computers.
If you enter 2002/januar, you expect the data for January and not for February. Right?

Translated with www.DeepL.com/Translator (free version)

[Mariusz Felisiak]

Well, then the documantation is wrong too!

I don't any issue in docs. Can you be more precise? (also please don't shout)

If I want to access the archive of the first week of a year, I call the link /year/1 and I expect to receive the data for this year and week numer one. But what I get is this year and week+1.

Or the other way, the user calls the webpage /2020/24, but gets a page for 2020/25. The page displays the data for week 25 and it has the title of week 25, Is this the expected result of a SEO friendly link?

If you're talking about an example from ​docs, then this behavior is documented:

"In this example, you are outputting the week number. Keep in mind that week numbers computed by the date template filter with the 'W' format character are not always the same as those computed by strftime() and strptime() with the '%W' format string. For year 2015, for example, week numbers output by date are higher by one compared to those output by strftime(). There isn’t an equivalent for the '%U' strftime() format string in date. Therefore, you should avoid using date to generate URLs for WeekArchiveView."

[RichardZimmerEschborn]

I DO understand, that the behavior is documented like it is.

BUT STILL: IT IS WRONG BEHAVIOR!

If a webpage produces and uses a link like:

​https://www.mysite.com/archive/2020/january, then the user and the search engine expect to find there the archive from january 2020
​https://www.mysite.com/archive/year/2020/month/01, then the user and the search engine also expect to find the archive from january 2020

If the same site produces a link like:

​https://www.mysite.com/archive/2020/week/20, then the user and the search engine expect to find there information from week 20.

But with this link Django will produce information for week 21 in this case. The link asking for the archive of week 20 returns the information of week 21!

THIS IS WRONG BEHAVIOR. It does not matter what the documentation says about it!

IT IS WRONG BEHAVIOR! SEO friendly means that the system produces, what is expected and not that it produces what a documentation (which is in the best case only read by programmers) says.

The URL to call the webpage does NOT generate the information which it suggests.

Maybe this should be a feature change, because it behaves like it is documentet, but the documented behavior is not what what users and search engines expect.

[Mariusz Felisiak]

If you need a different behavior, you can always use a custom subclass of WeekArchiveView or you're own view. Changing this behavior would be backward incompatible, but feel-free to start a discussion on DevelopersMailingList if you don't agree.

Again, please don't shout, your comments sound like a demand and it's not the best way to convince anyone, open-source doesn't work that way.