This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://dev.w3.org/html5/spec/Overview.html#dom-document-lastmodified Comment: This field would be better if specified to reuse the date format YYYY-MM-DD HH:MM:SS.
the Editor, Ian Hickson, seems (seemed) not to be against that proposal for a format which respects W3C Date and Time format. http://www.w3.org/TR/NOTE-datetime The issue is about implementations as I reported on my blog: http://www.la-grange.net/2010/10/14/dom-lastModified and in a Webkit bug report: https://bugs.webkit.org/show_bug.cgi?id=4363#c7 Cut and Paste here: ========================================================== 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 ========================================================== # Time zone issue Note that in addition of W3C Date and Time formats, there is the issue of the time zone. so far Opera and WebKit give the time zone of the resource *on the server*, but Firefox and IE give the date in the time zone of the user agent, which I guess is the time zone of the Operating System on which the user agent is working. The issue with the latter is that there is no way to have the exact lastModified date of the resource and could be an issue when comparing between two persons at different location discussing together.
FWIW, I recently landed a change in WebKit to follow the spec w.r.t. the time format of lastModified. The previous WebKit behavior was ... interesting.
(In reply to comment #1) > Only IE8 is aligned with the specification. Karl, read your blog and had seen the posts in 2007 about it, surprised at how the spec was defined. All stable (released) browsers have wildly different responses, yet Editor has standardised on one of those formats. Seems if the argument is to avoid breaking things, we already have a pile of breakage in previous browsers, so.. why should that stop a little more. I fear its probably too late to change things as Firefox 4 beta meets this spec and as comment #2 mentions WebKit too. But should they meet the current spec? This post seemed to have a reasonable solution, having it be a Date variable http://lists.w3.org/Archives/Public/public-html/2007Jun/0997.html > So how about: > * changing document.lastModified to a Date (or DOMTimeStamp) > * requiring that in ECMAScript bindings, toString() uses the > "MM/dd/yyyy HH:mm:ss" format (I know ECMAScript says the format is > implementation-dependent, but why couldn't we enforce it when used in > HTML?) The other suggestion (assuming corrected re: this bug) would be best served by a Date.toISOString method, but that is not relevant here. (In reply to comment #1) > "If the last modification date and time are not known, the attribute must > return the current date and time in the above format." If you have a long-running web application, how shall it know if the resource is genuinely that old or whether the date couldnt be inferred? Seems Operas behaviour is more sensible, defaulting to Epoch. ## (In reply to comment #1) > Note that in addition of W3C Date and Time formats, there is the issue of the > time zone. so far Opera and WebKit give the time zone of the resource *on the > server*, but Firefox and IE give the date in the time zone of the user agent IMO, keeping the timezone would be a safer option - you cant know if it may be useful in the future. Date can easily localise timezones so, win. ## (In reply to comment #2) Adam, obviously youve just written something im asking to have changed.. am I making sense, would it be worth it?
> All stable (released) browsers have wildly different responses, yet Editor has > standardised on one of those formats. Yep. That's why we like him. > I fear its probably too late to change things as Firefox 4 beta meets this spec > and as comment #2 mentions WebKit too. But should they meet the current spec? If all the browsers work the same way, I'm happy. > Adam, > obviously youve just written something im asking to have changed.. am I > making sense, would it be worth it? I don't think it would be worth it. What's in the spec is kind of goofy, but it's certainly not the goofiest thing in the platform. Let's worry about addressing more important use cases.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Converging on IE compatibility here improves interop and is consistent with the direction that other UAs are taking.
mass-moved component to LC1