Bug 4363

Summary: document.lastModified returns date in UTC time, but should return it in local time
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: WebCore Misc.Assignee: Pablo Flouret <pf>
Severity: Normal CC: abarth, cdumez, darin, dglazkov, haraken, ian, karlfschramm, karl+webkit, morrita, Ms2ger, ojan.autocc, peter+ews, pf, rc, rniwa, syoichi, webkit.review.bot
Priority: P3    
Version: 420+   
Hardware: Macintosh   
OS: OS X 10.4   
Description Flags
test case
Patch morrita: review-, morrita: commit-queue-

Description Alexey Proskuryakov 2005-08-09 13:32:32 PDT
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.writeln(" . ");	
   else {

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.
Comment 1 Alexey Proskuryakov 2005-10-01 05:42:46 PDT
I'm confirming this bug, as the behavior of document.lastModified  is clearly different from what Firefox 

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.
Comment 2 Eric Seidel (no email) 2005-12-28 01:12:32 PST
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.
Comment 3 Rüdiger Cordes 2006-04-19 02:35:17 PDT
I experienced that document.lastModified delivers no output at all?

Nightly of today is used.
Comment 4 Karl Schramm 2006-05-17 04:02:32 PDT
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.
Comment 5 Alexey Proskuryakov 2007-06-28 22:04:35 PDT
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.
Comment 6 Alexey Proskuryakov 2007-06-28 22:06:52 PDT
Created attachment 15306 [details]
test case
Comment 7 karl 2010-10-15 06:48:14 PDT
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 

"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
Comment 8 Syoichi Tsuyuhara 2012-12-07 06:52:12 PST
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".
>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.

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

Comment 9 Darin Adler 2012-12-07 09:06:22 PST
Retitled based on the most recent information in the bug, assuming it’s correct.
Comment 10 karl 2012-12-07 15:22:09 PST
Tested in Opera 12.11 Presto/2.12.388

Without Last-Modified header

Date: Fri, 07 Dec 2012 23:11:08 GMT

document.lastModified "12/08/2012 08:15:09"
new Date() Sat Dec 08 2012 08:15:09 GMT+0900

With Last-Modified header

Date: Fri, 07 Dec 2012 23:13:05 GMT
Last-Modified: Sat, 03 Nov 2012 22:09:55 GMT

document.lastModified "11/04/2012 07:09:55"
Comment 11 Pablo Flouret 2012-12-10 12:45:46 PST
Created attachment 178612 [details]
Comment 12 WebKit Review Bot 2012-12-10 12:55:29 PST
Comment on attachment 178612 [details]

Attachment 178612 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15258129
Comment 13 Peter Beverloo (cr-android ews) 2012-12-10 13:00:39 PST
Comment on attachment 178612 [details]

Attachment 178612 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/15259091
Comment 14 Pablo Flouret 2012-12-10 13:06:44 PST
Created attachment 178614 [details]
Comment 15 Syoichi Tsuyuhara 2012-12-17 19:45:01 PST
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 16 Hajime Morrita 2013-01-06 17:27:55 PST
Comment on attachment 178614 [details]

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.
Comment 17 Pablo Flouret 2013-01-07 16:52:18 PST
(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?
Comment 18 Hajime Morrita 2013-01-07 20:23:52 PST
(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.
Comment 19 Syoichi Tsuyuhara 2014-08-01 01:32:39 PDT
This Bug is fixed in Blink(Chromium 38.0.2111.0 (286952)).
Comment 20 Ms2ger (he/him; ⌚ UTC+1/+2) 2017-11-07 07:41:16 PST
Dupe of bug 149092?
Comment 21 Darin Adler 2017-11-07 09:06:49 PST
Yes indeed.

*** This bug has been marked as a duplicate of bug 14092 ***
Comment 22 Alexey Proskuryakov 2017-11-07 11:14:58 PST

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