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 17508,"DateDetailView should accept less specific dates, ie Year/Month or just Year",AndrewIngram,Moon Limb,"DateDetailView currently expects segments for year, month and day in the URL. This introduces the requirement to have an archive page for each level of the date; ie a year archive, a month archive, and a day archive: /2012/ /2012/jan/ /2012/jan/06/ /2012/jan/06/blog-entry-name/ I don't think I'm inaccurate in saying that most bloggers (as opposed to news sites) don't usually create more than one post a day, and many (myself included) have a frequency of much less than once per month. This means we're introducing views such as day archive that have exactly the same information as the higher levels. As a URL purist, I don't like unnecessary segments in my schema and unnecessary pages in my information architecture. In my case my URL structure is as follows, I don't use DayArchive at all: /2012/ /2012/jan/ /2012/jan/blog-entry-name/ I've achieved this by creating my own version of DateDetailView that removes the use of DayMixin, but I think this can also be achieved by modifying DateDetailView itself to allow looser date matching using configuration of the view itself. Is this a common enough use case to be worth making the change in Django itself? I think it can be done without affecting backwards compatibility.",New feature,assigned,Generic views,dev,Normal,,,andy@… hirokiky@… moonlimb@…,Accepted,1,1,1,0,0,0