Bug 4363 – document.lastModified returns date in UTC time, but should return it in local time

• Component: WebCore Misc.
• Status: RESOLVED DUPLICATE

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.

[Rüdiger Cordes]

I experienced that document.lastModified delivers no output at all?

Nightly of today is used.

[Karl Schramm]

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.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Created attachment 15306 [details]
test case

[karl]

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

[Syoichi Tsuyuhara]

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

[Darin Adler]

Retitled based on the most recent information in the bug, assuming it’s correct.

[karl]

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"

[Pablo Flouret]

Created attachment 178612 [details]
Patch

[WebKit Review Bot]

Comment on attachment 178612 [details]
Patch

Attachment 178612 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15258129

[Peter Beverloo (cr-android ews)]

Comment on attachment 178612 [details]
Patch

Attachment 178612 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/15259091

[Pablo Flouret]

Created attachment 178614 [details]
Patch

[Syoichi Tsuyuhara]

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.

[Hajime Morrita]

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.

[Pablo Flouret]

(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?

[Hajime Morrita]

(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.

[Syoichi Tsuyuhara]

This Bug is fixed in Blink(Chromium 38.0.2111.0 (286952)).
https://src.chromium.org/viewvc/blink?revision=179277&view=revision

[Ms2ger (he/him; ⌚ UTC+1/+2)]

Dupe of bug 149092?

[Darin Adler]

Yes indeed.

*** This bug has been marked as a duplicate of bug 14092 ***

[Alexey Proskuryakov]

*** This bug has been marked as a duplicate of bug 149092 ***