Thomas said:
For example, in my
Internet Explorer 6 and Iceweasel (Firefox) 3.5.3, document.lastModified
yields
10/22/2009 21:49:01
which does not even remotely resemble one of
| Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
| Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The Web server used was "Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with
Suhosin-Patch", and the relevant header was
Last-Modified: Thu, 22 Oct 2009 19:49:01 GMT
For the very same resource, I get
Thu, 22 Oct 2009 19:49:01 GMT
in Opera 10.00 and Konqueror 4.3.
For "Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT" (all relevant
content header values are taken straight from RFC):
Firefox: 11/15/1994 15:45:26
IE: 11/15/1994 16:45:26
Chrome: Tue, 15 Nov 1994 12:45:26 GMT
Safari: Tue, 15 Nov 1994 12:45:26 GMT
Opera: Tue, 15 Nov 1994 12:45:26 GMT
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
"Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Clients and servers
are
not required to use these formats for user presentation,
request
logging, etc."
HTML-date has 3 possible formats with only one that must be used and
the rest of legacy formats being only recognized. Client-side
document.lastModified default user representation may or may not
differ as allowed by the note above. In the particular and as an
instance Chrome, Safari and Opera use data "as is" while IE and
Firefox bring it to the format defined by the current OS locale
settings - the browser interface language and the page content
language do not alter this behavior, at least I didn't manage
yesterday to alter it by changing browser localization and Content-
Language header.
That btw seems allow to use an indirect way of getting an emulation of
IE's navigator.systemLanguage currently missing in Gecko. That is an
interesting practical outcome (to me at least).
document.lastModified - and here I do agree with Dr.Stockton -
intended to represent the date data in a convenient human readable
form, and this is the only thing that is guaranteed. For computer
input optimized format there are plenty of other tools server-side as
well as client-side.
If one needs to get normalized output in accordance with the HTTP/1.1
RFC then it is needed to use toUTCString on the newly created date
object and to account some toGMTString/toUTCString discrepancies with
some implementations placing "UTC" at the end (say IE) and some
placing "GMT" (say Firefox) with only "GMT" being correct by HTTP/1.1
HTML-date which is what we are normalizing to:
var lastMod = new Date(document.lastModified);
var HTML_date = lastMod.toUTCString().replace(/UTC/,'GMT');
A simple Perl script to play with if interested on the topic follows
below. As I noticed some Perl-purists around here
I added warning
and strict modes to keep everyone if not happy then at least relaxed
though I don't normally do it for the distribution ready software.
Do not forget to 755 under Unix and to change shebang if needed.
P.S. Modern browsers are ignoring Expires content header and relaying
on their own caching algorithms. If it's needed to update after some
changes use the regular ?randomsearch way.
--------------------------------------
#!/usr/bin/perl -w
use strict 'vars';
print "Content-Type: text/html; charset=iso-8859-1\n";
print "Content-Language: en-us\n";
print "Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT\n";
print "Expires: Thu, 01 Dec 1994 16:00:00 GMT\n";
print "\n";
print <<EndOfHTML;
<!DOCTYPE html>
<html lang="en-us">
<head>
<title>Test</title>
</head>
<body>
<h1>Test</h1>
<p>
<script type="text/javascript">
document.writeln('document.lastModified = ' +
document.lastModified + '<br>');
document.writeln('normalized form = ' +
(new Date(document.lastModified)).toUTCString().replace(/
UTC/,'GMT'));
</script>
</p>
</body>
</html>
EndOfHTML
exit(0);
