To FootSee "About This JavaScript Site" in JavaScript Index and Introduction.
See "General Date/Time Introduction" in JavaScript Date and Time Introduction.
Consider, throughout, the effects of changes in the Summer Time state.
It is reasonable to expect that a device that can fetch Web pages will be using an Internet time server, and so will be correctly set for UTC. Otherwise, PHP can put the current time in a Web page; that should if possible be done in UNIX milliseconds.
PSEUDOCODE : var Now = new Date( <?php echo +new Date() ?> ) // possibly
These clocks all use date and time as maintained by your computer.
For a running clock or countdown display, it is easier and safer not to count the seconds, minutes, etc. individually, but to determine at each instant what to display from the current time and the time when count is zero.
Note how timings are locked - for example in EachSecond - either to the clock second or to 10-5 of a day. Without that, in Win98 with IE4, ticks slipped from the proper timing, and some values did not appear. Later systems may not need it; but it does no harm.
See in date reference page for definitions.
Text and code here use Event throughout to refer to a specified occurrence; the upper-case E distinguishes it from a JavaScript event and its corresponding object.
It is simplest to count in seconds, or in fixed-length days; but one can count in Civil Days by allowing for Summer Time.
If the event is astronomical, give its time in UTC; if it is fixed-local, give the time with the numeric offset from UTC (alphabetic zone designations are unreliable); if it is local-to-reader, give no designation. Methods new Date & Date.UTC use UTC milliseconds. Run an update timer, and at each tick subtract new Date() from the event time. Use a function to convert milliseconds to display values, especially for multiple events. Don't repeat code.
function countdown(){
var today=new Date()
var todayy=today.getYear()
if (todayy < 1000)
todayy+=1900
...
There is, shown or used on various Web sites (seek "function countdown()"), a long routine starting as shown which computes the interval until a future Event in days, hours, minutes, and seconds.
The rest of that calculation is amateurishly over-long; the method in the next section is more efficient.
On the Web, I see many countdowns that are inefficient, incorrect, or both.
For multiple countdowns, each Event should be handled by a function call which is given just the time of the Event, the ID of the element to contain the result, the name of the Event, and the current time (and perhaps a display-formatting function). For clarity, the function can be used even for a single Event.
Here, function computeEvent(Event, Now) is used. The countdown Event object has properties .t .i .n .d for Time, ID to write in, Name, and (optional) Display function. Normally, the Time property of an Event will be of the form new Date("YYYY/MM/DD hh:mm:ss UTC"); the forms used here were chosen for easy testing. Note that offset designators other than GMT & UTC may not be recognised by all browsers; Opera 9.50, for example.
The following assumes that one or more Events, each definable in UTC, are to be displayed in a manner given by function DisplayEvent, which can be replaced as required (usually by something more decorative). Here, when the Event occurs, the legend will change and the count will reverse. LCT means the reader's Local Civil Time. The reader's browser's clock is assumed correct.
A function DisplayEvent can, of course, be given the ID of an element which contains sub-elements for the individual fields. If there are a number of parallel counts, the destinations can be generated by a code loop.
For a Rota of Events (here set to two Events occurring today) :-
For test; best done early in a clock minute.
Time : Last : Next :
To 1 day 00:01:40 from page load,
. d .:.:.
The OS settings are not infallible; see my Summer Time page, which also gives clock change rules and algorithms.
Such settings may be read from the OS when the browser is started, when the page is opened, or when needed. It is not clear which is best, nor whether there is a standard. Browsers do differ here.
One can calculate the changes from known location and Rules, and can determine them for the current location by investigating the behaviour of getTimezoneOffset.
See also in 5: Date and Time Elsewhere and Opera Summer Time.
By current Rules, Summer Time in the EU is between the last Sundays of March and October, with the change at 01:00:00 GMT/UTC throughout. Rules elsewhere vary.
Modification for NA should be easy enough; see in Summer Time.
This gives the EU change date/times for the present UTC year.
Note that "after your clock" relies on your OS settings.
The Time Zone Offsets for January and July give the Standard Offset and, if different, North/South and, in conjunction with the current Offset, Winter/Summer.
The Standard Offset, above, is (Local-GMT); GMT+Offset = Local.
See also 0: Date Object Information.
It can be presumed that one change is in the range from January 1st to July 1st, for which dates one can determine the Offsets from GMT. By splitting the difference and determining the Offset there, one can halve the range in which the change may lie. Repeating that about 20 times locates the change sufficiently well. The other change is located similarly.
N.B. Functions TimeChangeDates, SummerTimeDates are rather similar. This part needs more consolidation.
A TZ string is a compact notation for describing the difference between local time and GMT, including seasonal changes.
For any GMT date/time in range, a JavaScript call of getTimezoneOffset (mis-named) can obtain the offset between that local time and GMT, using the system's current-date rules for its location. With that, one can get the Winter and Summer offsets, and, if Summer Time is used, the rules, which are M-type (for the N'th X-day of a fixed month) or J-type (for fixed -MM-DD). The acronyms for offsets (GMT BST etc.) are not available in general, and std smr are used here instead.
If Summer Time occurs at the user's set location, the code checks whether each clock change is M-type or J-type. Seven Leap Years are used to distinguish possible M2.5.#. The code is not optimised for execution time.
Note that testing for various locations is needed.
Almost all places with Summer Time use M-type rules. Mauritius and Morocco may have J-type Summer Time rules. Iran is incompatible, being non-Gregorian J-type. The Israeli Summer Time Rules currently (2008) defeat the code, as neither start nor finish is TZ-compatible . There may be other exceptions. For any location, a Rule can be written for each individual year. See Daylight saving time around the world.
Using WinXP sp3 on 2008-10-30 :
With UK settings, I got :
Your draft TZ string is : std0smr,M3.5.0/01:00,M10.5.0/02:00
With US Eastern settings, I got :
Your draft TZ string is : std5smr,M3.2.0/02:00,M11.1.0/02:00
With Jerusalem settings, I got,
Your draft TZ string is : std-2smr,M3.5.5/02:00,M10.1.0/02:00
though the latter may match only the 2008 dates.
My (in UK) Opera 9.21 .. 9.27, 9.50, 10.10 get that wrong, the years being outside 1970 to 2038;.
Opera 9.27, 9.50 show me obvious errors from 2038.
UNIX time_t is measured in seconds from 1970-01-01 00:00:00 GMT, from which JavaScript measures milliseconds; there are no steps for Summer Time and in JavaScript there should be no Leap Seconds.
UNIX time_t significant seconds
N.B. ECMA-262 requires that Leap Seconds (and variations from the current Summer Time Rules or Time Zones) are ignored. UNIX-type systems may not comply.
A Web server normally sends a well-specified Last-Modified: header line, from which should be derived a JavaScript document.lastModified string, which is ill-specified and can be badly implemented. The header line generally reflects the date-stamp of the file on the server.
The server date-stamp is often, but is not necessarily, updated each time that the file is written to the server.
See Reading HTTP Headers : Last-Modified.
The current document.lastModified string for this page (see the hand-entered date at the head of this page) and your browser is :-
Consider the applicable Time Offset, the date field order, and Y2k. My MSIE4 (in UK) failed to satisfy for all three, and its new Date() would interpret it as local time instead of GMT and a century too early. My MSIE6 and MSIE7 showed, and my MSIE8 shows, a 4-digit year, local time, with US field order (FFF).
Your browser's new Date() gives for this page :-
If any problems at all are suspected in the use of lastModified then first display it as a string, in order to be sure of the starting point.
Note that the date and time are those of the latest upload of the specified page to the server, unaffected by those of any included files. One must not presume that it corresponds to any significant change in the page content.
See also in VBScript Date and Time 2.
The document.lastModified string for a general Web page can be shown by executing javascript:alert(document.lastModified) in the address bar.
The simple, reliable method of indicating page date is for the author to put the information into the HTML when editing, which also means that the indicated date need not vary when only trivial changes (e.g. spelling) are made.
Those uploading scriptably (e.g. by FTP at a DOS/UNIX prompt) should be able to auto-alter text within a file before upload, using a scriptable editor such as SED or MiniTrue. For DOS, my program NOWMINUS can format the date.
Also, ASP pages can add the file date, formatted server-side.
Remember to choose an unambiguous format, and consider the offset from GMT. The default time-zone assumption should be the author's civil date/time. I use the UK civil date at the head of each page.
(Safari (3.1.2) gives an empty string when reading my local file.)
The page header which is sent from a Web server to a browser should include a non-mandatory Last-Modified: header line for the date and time when the page was last changed on the server.
The transmission format is unambiguously specified, and is itself completely unambiguous. It uses four digits for the year; and it redundantly includes day-of-week, which I expect will always be sent but ignored. It has been specified in RFC 2068 and RFC 2616 ("HTTP/1.1"), Secs. 3.3 : "Date/Time Formats" and Secs. 14.29 : "Last-Modified".
It is as :- Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
I believe that the server used for www.merlyn.demon.co.uk at Demon sends in the correct format, but with lower-case m .
Note : the value sent usually relies on the server's clock having been properly set at the time of FTP upload. It may be, though, that the value can be set in some other manner.
Some give an empty string for a local file.
My IE4 gave "MM/DD/YY hh:mm:ss", in implicit GMT. My IE6 gave "MM/DD/YYYY hh:mm:ss", in implicit LCT. My IE7 gave "MM/DD/YYYY hh:mm:ss", in implicit LCT. My IE8 gives "MM/DD/YYYY hh:mm:ss", in implicit LCT. My FF3 gives "MM/DD/YYYY hh:mm:ss", in implicit LCT. My Op9 gives "Day, DD Mon YYYY hh:mm:ss GMT". My Sf3 gives "Day, DD Mon YYYY hh:mm:ss GMT" (local: an empty string). Chrome gives "Day, DD Mon YYYY hh:mm:ss GMT" (local: an empty string).
The date format in the JavaScript lastModified string is browser-dependent and can be misleading when read. In particular, time zone, field order & size, and separators may vary. It seems likely that a browser's new Date() and Date.parse() will always read it correctly, apart from possible century and time zone errors. In the browser which I used earlier (MSIE4), it was in (un-indicated) GMT with a 2-digit year, so new Date() defaulted to local time and previous century.
The string representation from lastModified is seemingly at the whim of the displaying browser. Consequently Y2k error is possible.
It may be safer, until the Web is 100 years old, to present the 2-digit year and omit Day-of-Week.
Formats that I know about for the JavaScript lastModified string :- MM/DD/YY hh:mm:ss GMT e.g. MSIE 4, Win 98, UK MM/DD/YYYY hh:mm:ss e.g. MSIE 6, Win XP, UK ... YYYY .... e.g. NS 4.7 Day, DD Mon YYYY hh:mm:ss GMT Opera 9, UK Grant Wagner, on Windows 2000 :- IE 5.5 SP2: 05/17/2002 16:27:17 Netscape 4.78: Friday, May 17, 2002 16:27:33 Netscape 6: Friday, May 17, 2002 16:27:49 Opera 6.02: Fri, 17 May 2002 15:28:27 GMT See also in JavaScript:document.lastModified - Bisherige Ergebnisse (old)
Please let me know of other formats seen. My Test Page for JavaScript lastModified is a fairly minimal page showing the format that your browser gives.
It seems to be common for the Last-Modified: header line to be copied into JavaScript lastModified which seems sensible; I don't know whether the month and day are ever translated from English.
If Last-Modified: is not supported by the server, and the line is not received by the browser, the results are browser-dependent. I have read that the lastModified string may be set locally either to correspond to new Date() (e.g. MSIE; the current instant by the local clock) or to new Date(0) (e.g. NS; "January 1, 1970 GMT", allegedly with no time field).
Setting the string to blank or to Undefined or Unknown date would have been sensible.
Also, the string may be empty,
Coders often neglect to allow for the "no data" case, and/or for possible format differences between browsers, when re-formatting the information.
A value corresponding to new Date(0) is liable to be displayed as the local-to-browser date/time corresponding to 1970-01-01 00:00:00 GMT. "Y2k correction" may then give 2070. New Worlders may see Dec 31 1969, or 2069.
A confidence-test for lastModified interpretation can be programmed, by noting that when a page is fetched its modification moment must be greater (allowing for clock error) than the date of editing its code; so I can now assert that you should be seeing a lastModified for this page which is later than 2007-03-29 13:50:00 GMT.
In practice, a coder might check that the date/time is not earlier than the year of coding and is perceptibly before the current instant. Most coders can now assume a year range of 2000-2099 or less.
These present what my server sends to your browser, as interpreted by your browser and further by my code. Compare the results with the date at the top of this Web page, which is in manual HTML (actual upload to the server may be later).
The code assumes that the date is GMT, but that it may not say so. Nowadays, that assumption should probably be reversed.
The code has Y2.1k errors, which need to be corrected about mid-century.
Note that it contains imported functions; see in Date and Time Introduction.
Since ISO/IEC 16262 does not specify the results of the string-output methods of Date Objects, I recommend, for reliable results, not using any of them. Instead, build the string using the "get..." methods and a leading-zero routine if appropriate.
When testing display code, always first display the raw lastModified string itself, to see exactly what it may be.
That assumes 2000 ≤ Year < 2100.
If SSI is available, it can be used to provide a modification date/time in a selecctable, internationally-compatible format; I test that in Server Side Includes.