#11197 closed (invalid)
django.utils.dateformat for 'W' is not correct
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Template system | Version: | 1.0 |
Severity: | Keywords: | dateformat | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have a simple problem with the datebased view archive_week.
In the generic view is something like:
In [23]: date = datetime.date(*time.strptime('2009-0-22', '%Y-%w-%U')[:3]) In [24]: date Out[24]: datetime.date(2009, 5, 31)
BUT the template-tag "date" does the following (and here's the bug):
In [19]: now = datetime.datetime.now() In [20]: now Out[20]: datetime.datetime(2009, 5, 25, 12, 2, 46, 964892) In [21]: df = DateFormat(now) In [22]: df.format("%W") Out[22]: u'%22'
so my python installation tells me the first day of the 21st week of 2009 was yesterday, but my django installation tells me we have one day later already the 22nd week wich is starting at 31st.
this is a real problem if you write something like this in your templates:
<a href="{% url aggregator_archive_week year=entry.timestamp_created|date:"Y", week=entry.timestamp_created|date:"W", slug=stream.slug %}">
Change History (2)
comment:1 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 16 years ago
right, thanks for that answer. but my initial problem stays:
wich leads me due to the inconsistency to an own templatefilter :-(
Summary says django.utils.dateformat for "W" is not correct, but near as I can tell the results for dateformat "%W" are correct as documented here: http://docs.djangoproject.com/en/dev/ref/templates/builtins/#now
which says %W returns the ISO-8601 week number of the year, with weeks starting on Monday. Doing a little research, you'll find ISO-8601 week number ranges from 1 to 53, where 1 is the the week with the first Thursday in it. As Jan 1, 2009 was a Thursday, it was in week 1 by ISO-8601 definition.
As you show, Django is returning 22 for this value for the date May 25, 2009, which agrees with the calendar on this page: http://en.wikipedia.org/wiki/ISO_week_date. By ISO-8601 definitions May 25, 2009 is the first day of week 22.
The description goes into more detail about trouble resulting from using the results of this dateformat option as input to the
week
parameter of a generic view. The generic view uses Python's "%U" strftime formatting definition for week number, found here: http://docs.python.org/library/time.html#time.strftime. It is: "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." By Python's definition Jan 1, 2009 was in week 0, not week 1 as it is by ISO-8601 definition, and that leads to the difference you observe for the May 25, 2009.If there is some place within Django that tries to interchange these values then there might be a bug there, but what you mention is a link you have placed in your template that uses the result of %W dateformat documented to return an ISO-8601-defined value as input to the archive_week generic view
week
parameter that is documented (http://docs.djangoproject.com/en/dev/ref/generic-views/#django-views-generic-date-based-archive-week) to be "The week of the year for which the archive serves (a string). Weeks start with Sunday." They are different ways of numbering weeks and cannot be interchanged like that.It's unfortunate that there are so many differing standards for numbering and dates, and it would certainly be preferable if only one existed, but that's not reality. Django supports retrieving an ISO-8601 week number in one place but requires a different week numbering scheme elsewhere...not ideal perhaps but all working as documented so I don't see a Django bug here.