In Firefox, document.lastModified is just the string from Last-Modified http header. Some sites rely on this; for example, http://www.sbrf.ru (one of the largest banks in Russia) has the following code: function LastMod(){ if (navigator.appName == "Microsoft Internet Explorer"){ document.writeln(document.lastModified.substring(3,5)); document.writeln(" . "); document.writeln(document.lastModified.substring(0,2)); document.writeln(" . "); document.writeln(document.lastModified.substring(6,10)); } else { document.writeln(document.lastModified.substring(5,16)); } } They send "Last-Modified: Tue, 09 Aug 2005 13:53:52 GMT", and this results in "09 Aug 2005". However under Safari, this becomes "ug 09 2005 " (at the bottom right of the page), presumably because Safari creates and then serializes a Date object.
I'm confirming this bug, as the behavior of document.lastModified is clearly different from what Firefox does. At the same time, the site in question (www.sbrf.ru) has changed its code, and this issue no longer affects it, so I'm lowering the priority.
I agree, this should internally just be a DOMString. Simple fix for someone wanting to dive into a little JavaScript bindings/a little DOM code.
I experienced that document.lastModified delivers no output at all? Nightly of today is used.
It seems WKGetNSURLResponseLastModifiedDate() is not giving a proper lastModified date. Since this function is in WebKitLibraries, someone on the "inside" will have to take a looksee.
Actually, it appears that no browser preserves the format - Opera prints the Last-Modified date as RFC 822 (HTTP preferred format), while Firefox 2 and MSIE 7 print as "08/09/2005 17:53:52". The latter behavior is specified in HTML 5 draft, too. Judging from the site code, I suppose that Netscape/Mozilla behavior has changed at some point. (In reply to comment #3) > I experienced that document.lastModified delivers no output at all? See bug 8475.
Created attachment 15306 [details] test case
There is a subtle difference between Firefox and IE. I have tested yesterday with different browsers the dates returned when HTTP Last-Modified is not returned by the server. HTML5 specification says http://www.w3.org/TR/html5/dom.html#dom-document-lastmodified "The Document 's source file's last modification date and time must be derived from relevant features of the networking protocols used, e.g. from the value of the HTTP Last-Modified header of the document, or from metadata in the file system for local files." For a page where the HTTP header is Last-Modified: Wed, 13 Oct 2010 17:11:52 GMT Opera 10.63 - Wed, 13 Oct 2010 17:11:52 GMT Safari 5.0.2 - Wed, 13 Oct 2010 17:11:52 GMT chrome v6.0.472.63 - Wed, 13 Oct 2010 17:11:52 GMT Firefox 4.0b6 - 10/13/2010 13:11:52 IE8 - 10/13/2010 13:11:52 Conclusion IE8, Firefox are aligned with the specification. When Last-Modified is not defined, HTML5 says: "If the last modification date and time are not known, the attribute must return the current date and time in the above format." The results are: Opera 10.63 - January 1, 1970 GMT Safari 5.0.2 - Nil chrome v6.0.472.63 - Nil Firefox 4.0b6 - 10/13/2010 14:36:31 (date of the cache) IE8 - 10/13/2010 14:53:22 (date of now) Only IE8 is aligned with the specification. Note that the HTML5 Specification editor welcomes modifications to the specification if implementers decide to align on one format. One of the issues is the proposed format in the specification is a US one, aka "MM/DD/YYYY HH:MM:SS" See http://lists.w3.org/Archives/Public/public-html/2007Jun/1005
Only WebKit still has this bug about document.lastModified. According to HTML Living Standard, document.lastModified should return the date and time in "local time zone". >document.lastModified >Returns the date of the last modification to the document, as reported by the server, in the form "MM/DD/YYYY hh:mm:ss", in the user's local time zone. >If the last modification date is not known, the current time is returned instead. http://html.spec.whatwg.org/multipage/dom.html#dom-document-lastmodified On Windows 7 Home Premium SP1 64bit, IE 9.0.11 and Firefox 17.0.1, Opera 12.11 x64 correspond to this. But WebKit r131444 and Chromium 25.0.1353.0 (171761) return a date and time in UTC(GMT). screenshot: http://cache.gyazo.com/003b6a7437c790666e22dd375a068c55.png related: https://bugs.webkit.org/show_bug.cgi?id=8475 http://code.google.com/p/chromium/issues/detail?id=2400
Retitled based on the most recent information in the bug, assuming it’s correct.
Tested in Opera 12.11 Presto/2.12.388 Without Last-Modified header Server: Date: Fri, 07 Dec 2012 23:11:08 GMT Client: document.lastModified "12/08/2012 08:15:09" new Date() Sat Dec 08 2012 08:15:09 GMT+0900 With Last-Modified header Server: Date: Fri, 07 Dec 2012 23:13:05 GMT Last-Modified: Sat, 03 Nov 2012 22:09:55 GMT Client: document.lastModified "11/04/2012 07:09:55"
Created attachment 178612 [details] Patch
Comment on attachment 178612 [details] Patch Attachment 178612 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15258129
Comment on attachment 178612 [details] Patch Attachment 178612 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/15259091
Created attachment 178614 [details] Patch
Reviewers, please review Pablo Flouret's patch. I think that this bug should be fixed as soon as possible, because only WebKit has still this bug.
Comment on attachment 178614 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=178614&action=review > Source/WebCore/dom/Document.cpp:3845 > { The approach looks good. I'd like to take this fix as an opportunity to extract a function which returns DateComponents. foundDate flag seems wrong idea.
(In reply to comment #16) > > The approach looks good. > > I'd like to take this fix as an opportunity to extract a function which returns DateComponents. What should this function do?
(In reply to comment #17) > > I'd like to take this fix as an opportunity to extract a function which returns DateComponents. > > What should this function do? It'd be just an extraction from the original function. One returns the DateComponent, and another (Document#lastModified()) formats it into String.
This Bug is fixed in Blink(Chromium 38.0.2111.0 (286952)). https://src.chromium.org/viewvc/blink?revision=179277&view=revision
Dupe of bug 149092?
Yes indeed. *** This bug has been marked as a duplicate of bug 14092 ***
*** This bug has been marked as a duplicate of bug 149092 ***