I just discovered that the condition decorator does check for exact match only, too. Thus, the ticket should be changed to also include this issue. Is someone going to reopen the ticket?
On Aug 9, 11:46 pm, Łukasz Rekucki <[email protected]> wrote: > On 9 August 2010 22:48, Paul McMillan <[email protected]> wrote:> I agree with > the person who closed the ticket again, since this should > > have been discussed on the mailing list prior to re-opening it. > > That would be me ;) > > > > > That said, I'm strongly +1 on this issue. I've had to write > > workarounds for exactly the described behavior on other systems, and > > it hasn't been good. Django should follow the RFC and do the sane, > > rational thing. There are a myriad of use cases these days for > > retreiving an object without storing the precise previous retrieval > > time. > > The "follow RFC" argument is not that strong. It actually advises > clients to use the exact date string that was previously returned by > server if possible. It also notes a few problems when using arbitrary > dates. A valid use case is far more convincing. If Google's crawler is > causing problems, it's probably worth fixing. > > As for the patch, it only parses one of three date formats required by > the RFC[1]. So if you want to strictly follow the RFC, it must parse > all three. > > Just my 2 cents. > > [1]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 > > -- > Lucas Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
