reptile7's JavaScript blog
Tuesday, February 11, 2014
Does Anybody Really Know What Time It Was?
Blog Entry #309

It's been a couple of months since the last reptile7's JavaScript blog entry so let me get back into the groove with something simple. In today's post we'll check over the Scripts that Display Text collection's "Full Date Since…" script, which was authored by Jay Reed in February 1999. The Full Date Since… script prints out for the user two time-related pieces of information, namely,
(1) the time at which the user arrived at the current page and
(2) the time at which the current page was last modified.
You can access the Full Date Since… script here and see its effect here.

The script

In February 1999 the current versions of IE* and Netscape were IE 4.x and Netscape 4.x, respectively. (*Beta versions of IE 5 had been released and a final IE 5 version was out a month later.) A complete separation of structure, presentation, and behavior was possible with IE 4.x but not with Netscape 4.x, so to accommodate users of the latter browser(s) Jay formulated the Full Date Since… code as a single all-encompassing script element:

<script language="javascript"><!--
/* Written by Jay Reed,
Permission to use granted to all who keep this text enclosed */
document.write("<b><font size='3' color='navy'> You have been here since:<br><tt><font size='3' color='red'> " + Date( ) + " </font></b><br>");
document.write("<b></font><font size='3' color='navy'></tt>Page last updated:<br><tt></font><font size='3' color='red'> ");
document.write(" </font></b></tt>");
//-- end Date --></script>

Time outputs


We get the You have been here since: time (and a bit more) by simply writing Date( ) to the page. Mozilla explains:
Calling [JavaScript's Date] as a regular function (i.e., without the new operator) will return a string rather than a Date object.
With Firefox, Opera, and Safari on my computer, the Date( ) output has the following format:

Fri Feb 07 2014 13:00:00 GMT-0800 (PST)

If you just want to display the time without the date at the beginning or the time zone stuff at the end, then you can trim the Date( ) string with the String object's substring( ) method, i.e., Date( ).substring(16, 24).

More modernly but less consistently, a new Date( ).toLocaleTimeString( ) command will also give us a time string.
• Firefox's toLocaleTimeString( ) return is based on a 24-hour clock: 13:00:00
• Opera's toLocaleTimeString( ) return is based on a 12-hour clock and includes an AM/PM designator: 1:00:00 PM
• Safari's toLocaleTimeString( ) return is based on a 12-hour clock and includes AM/PM and time zone designators: 1:00:00 PM PST


We (attempt to) get the Page last updated: time by reading the lastModified property of the document object. Specification-wise, document.lastModified goes back to JavaScript 1.0, currently has a DOM Level 0 status, and is being brought into HTML5. We very briefly discussed document.lastModified way back in Blog Entry #13 but haven't seen it since.

In order for document.lastModified to provide the document's last modification date and time, the server must be configured to include an HTTP Last-Modified header when it serves the page. In the absence of a Last-Modified header the W3C declares that document.lastModified must return the current date and time
(a) in the form MM/DD/YYYY hh:mm:ss and
(b) in the user's local time zone.
Upon testing these criteria at several high profile Web pages* that are not served with a Last-Modified header, I find that Firefox complies with both (a) and (b) whereas Opera and Safari comply with (a) but give a UTC time (and presumably date) for (b).

*,,, and, whose HTTP headers were determined via Rex Swain's HTTP Viewer.


Excepting the br elements, the document.write( ) parameter markup
(1) serves a purely presentational purpose (an argument can be made that the <br>s also serve a presentational purpose) and
(2) is improperly nested (or would be improperly nested, if we were writing the markup normally and not scriptically).

The font and tt elements are defined in the "Alignment, font styles, and horizontal rules" chapter of the HTML 4.01 Specification. The font element was deprecated by HTML 4 but the tt element wasn't; both elements appear in HTML5's Non-conforming features section: Elements in [this] list are entirely obsolete, and must not be used by authors.

According to the CSS 2.1 Specification, a size='3' font element attribute should map onto a font-size:medium; style declaration, and that's what I observe on my computer. As medium is the initial value of the font-size property we can just throw out the size='3' attributes without replacing them with anything. The color='navy' and color='red' font element attributes can and should be respectively replaced by color:navy; and color:red; style declarations.

The tt element renders [its text content] as teletype or monospaced text. (Do you know what a teletype is? I didn't, and had to go look it up.) The tt markup can be traded in for a font-family:Courier,monospace; declaration.

You can keep the b elements if you want - they're legit in both HTML 4.x and HTML5 - but in the name of clutter reduction I myself would exchange them for a font-weight:bold; declaration.


HTML features a samp element for designating sample output from programs, scripts, etc. and that would be appropriate for marking up the aforediscussed time outputs. The browsers on my computer render samp text in a monospace font, so you could probably lose the font-family:Courier,monospace; tt replacement depending on how important it is to you.

The time outputs can be loaded into the samps via a window.onload-triggered function:

window.onload = function ( ) { document.getElementById("sinceSamp").innerHTML = Date( ).substring(16, 24); document.getElementById("updateSamp").innerHTML = document.lastModified; }
You have been here since:<br>
<samp id="sinceSamp"></samp><br>
Page last updated:<br>
<samp id="updateSamp"></samp>

The body element has a block-type content model in the X/HTML Strict DTDs and a flow-type content model in the X/HTML Transitional DTDs so the widget as a whole should be placed in a div element if you're going to strictly validate the container document; an outer div is unnecessary for a transitional validation or for no validation at all but still makes sense from a semantic viewpoint.


You have been here since:

Page last updated:

FYI: The page does return a Last-Modified header.

Comments: Post a Comment

<< Home

Powered by Blogger

Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)