GMT Date Format Anomaly

[clintonG]

When the following code is run on Sat Dec 25 2004 19:54:18 GMT-0600 (Central
Standard Time)

var today = new Date();
var GMTDate = today.toGMTStri ng();
document.write( "GMTDate: " + GMTDate);

The code returns:
Sun, 26 Dec 2004 19:54:18 GMT (the next day after the code was actually run)

Please advise why the day is in the future and suggest how to get the
correct GMT date format.

<%= Clinton Gallagher

[Dr John Stockton]

JRS: In article <cq************ *******@news.de mon.co.uk>, dated Tue, 28
Dec 2004 16:05:17, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

clintonG wrote:

So-called 'we support standards' FireFraud 0.9.3 returns the text GMT in the
string returned by the toUTCString method but the 'evil' IE returns UTC as
expected.

There is no defined output format for UTC (which is an *internal* means
of representing time set at GMT for general use - pureply "cosmetic") .
The correct display format in ALL cases will be "GMT" and that is what
you should see.

There is at least one browser still in use in which
new Date() -> Tue Dec 28 20:42:00 UTC 2004
new Date().toGMTStr ing() -> Tue, 28 Dec 2004 20:42:52 UTC
new Date().toUTCStr ing() -> Tue, 28 Dec 2004 20:43:28 UTC
new Date().toLocale String() -> 12/28/2004 20:44:14
with UK localisation.

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Mark Preston]

Dr John Stockton wrote:

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.

The wise reader will also know that GMT and UTC are the same thing.
Unfortunately, as we all know, wise readers are as rare as rocking-horse
droppings... :)

[McKirahan]

"Mark Preston" <us****@nosourc e.co.uk> wrote in message
news:cr******** ***********@new s.demon.co.uk.. .

Dr John Stockton wrote:

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.

The wise reader will also know that GMT and UTC are the same thing.
Unfortunately, as we all know, wise readers are as rare as rocking-horse
droppings... :)

GMT vs. UTC
http://sts.sunyit.edu/timetech/gmt-utc.html

The development of highly accurate cesium-beam atomic clocks led to the
redefinition of the second in 1967. This led to the recognition by
scientists and technologists of the inadequacy of measuring time based on
the erratic motion of the earth whose rate fluctuates by a few thousandths
of a second a day. Attempts to couple GMT, based on the earth's motion, and
the new definition of the second was highly unsatisfactory. A compromise
time scale, Coordinated Universal Time (UTC), was devised and became
effective on January 1, 1972.

GMT vs. UTC
http://people.etango.com/~markm/arch...mt_vs_utc.html

Last night at dinner a tangential conversation got us on the topic of GMT
vs. UTC. None of us knew the exact difference between the two except for
that UTC was newer and more exact. So, I looked it up. Here is a good, brief
description from the State University of New York Institute of Technology's
Science & Technology Society (man that is a mouthful). Basically it comes
down to GMT being based on the rotation of the earth around its axis and the
sun (which isn't completely regular) and UTC being based on a Cesium atomic
clock (which is far more accurate and regular). UTC is regularly modified
with "leap seconds" so that it matches up to GMT to be the standard for
date/time stamps. Also, UTC is the authoriative measurement for calculations
involving duration.

Update: Corrected, which unit gets leap seconds added. Thanks Daniel for
pointing out my mistake.

[Dr John Stockton]

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Dr John Stockton wrote:

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.

The wise reader will also know that GMT and UTC are the same thing.
Unfortunatel y, as we all know, wise readers are as rare as rocking-horse
droppings... :)

No, GMT and UTC are not the same thing, even apart from what I was
referring to, which is that a coder must allow for the possibility of
getting either string from a Date Object method.

Javascript treats them as synonymous, and implements time as GMT; few
computers have the information needed to implement UTC.

GMT has 24 * 60 * 60 seconds in EVERY day [@], but the seconds are of
slightly varying length so that, on average, GMT Noon is at mid-day at
Greenwich.

UTC has 24 * 60 * 60 SI seconds in most days, and the seconds are of
constant length[+], but occasionally there can be one added or omitted,
so that, on average, UTC Noon is at mid-day at Greenwich.

Those are a sort of average mid-day - look up "Equation of Time".

The difference between UTC and GMT is kept under, IIRC, 0.9 seconds.

Above, UTC means UTC; but IIRC GMT above may mean some other timescale,
perhaps UT, with similar properties - GMT itself being now deprecated.

See <URL:http://www.merlyn.demo n.co.uk/leapsecs.htm>, etc.
The above is not precision-grade; for that, refer to such as NPL, NIST,
and "The International Earth Rotation Service (IERS)" at
<URL:http://hpiers.obspm.fr/>.

The advantage of GMT, as a term, is that it is generally interpreted as
needed, with days each containing 86400 parts; as opposed to UTC, where
each day contains 86400+-1 SI seconds. Javascript has no support for
Leap Seconds. It accepts new Date("2005/06/30 23:59:59 UTC") here as
nearly Jul 1 0100h, but considers new Date("2005/06/30 23:59:60 UTC")
as meaning NaN, whereas that second *may* occur.
Be aware that, unless recently changed, UK legal time is GMT, but time
signals here are UTC. The cautious drinker will prudently drain his
glass at least 0.9 seconds before the stipulated moment seems to appear;
and it would be interesting to argue on such a basis about a marginal
case of Ken Livingstone's congestion charge.

[@] Except 1924 Dec 31 GMT or 1925 Jan 1 GMT.

[+] La seconde est la duree de 9 192 631 770 periodes
de la radiation correspondant a la transition entre les deux
niveaux hyperfins de l'etat fondamental de l'atome de cesium 133
(CGPM 13, 1967, Resolution 1). [Francophones add accents to taste.]

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Mark Preston]

Dr John Stockton wrote:

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Dr John Stockton wrote:

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.

The wise reader will also know that GMT and UTC are the same thing.
Unfortunately , as we all know, wise readers are as rare as rocking-horse
droppings.. . :)

No, GMT and UTC are not the same thing, even apart from what I was
referring to, which is that a coder must allow for the possibility of
getting either string from a Date Object method.

Technically, you are correct. GMT is a standard-period time recording
(that is, it counts how long the Earth takes to revolve) and is
consequently "inaccurate " since nothing in this life is as simple as a
spinning planet is assumed to be. UTC, on the other hand, is a derived
probabilistic decay-rate measurement.

But, be honest, who really cares about the odd leap-second or so?

[Dr John Stockton]

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Mon, 3
Jan 2005 16:31:02, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Dr John Stockton wrote:

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Dr John Stockton wrote:

The wise programmer will allow for getting either UTC or GMT (and know
that the two are not synonymous, and in principle neither is correct).
AFAIK, however, one need not expect utc or gmt.
The wise reader will also know that GMT and UTC are the same thing.
Unfortunatel y, as we all know, wise readers are as rare as rocking-horse
droppings. .. :)
No, GMT and UTC are not the same thing, even apart from what I was
referring to, which is that a coder must allow for the possibility of
getting either string from a Date Object method.

Technically, you are correct. GMT is a standard-period time recording
(that is, it counts how long the Earth takes to revolve) and is
consequently "inaccurate " since nothing in this life is as simple as a
spinning planet is assumed to be.

Approximately correct.
UTC, on the other hand, is a derived
probabilisti c decay-rate measurement.
Total rubbish. It has nothing at all to do with decay rates. UTC is
based on the SI second, which is based on a precise transition of Cs-133
(see footnote [+] to my previous article), plus adjustments to make it
agree with one of the GMT-class time scales to within 0.9 seconds.

See my WWW site, and confirm by means of the links it contains; do not
trust amateur sources.
But, be honest, who really cares about the odd leap-second or so?

Quite a number of people care quite a lot - granted, only a minority
know, but many more could be affected if a mistake were made.
The important things for this group remain that (a) one can never be
really safe in assuming that a string generated by the javascript
processor will not include GMT where UTC might be expected, or /vice
versa/, (b) javascript knows nothing of leap seconds, and behaves
arithmetically as GMT does.

--
© John Stockton, Surrey, UK. *@merlyn.demon. co.uk / ??*********@phy sics.org ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

[Mark Preston]

Dr John Stockton wrote:

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Mon, 3
Jan 2005 16:31:02, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

UTC, on the other hand, is a derived
probabilist ic decay-rate measurement.

Total rubbish. It has nothing at all to do with decay rates. UTC is
based on the SI second, which is based on a precise transition of Cs-133
(see footnote [+] to my previous article), plus adjustments to make it
agree with one of the GMT-class time scales to within 0.9 seconds.

See my WWW site, and confirm by means of the links it contains; do not
trust amateur sources.

Umm - yes, it is. But as I just pointed out in one sentance exactly the
same thing I don't see your problem.

In case you are not sure why they are the same then I suggest you look
again at your description which nicely summarises that UTC is based on
decay transitions of Caesium 133 and ordered to a standardised average
(which is what the SI units are all about). Why average? Well, because
decay rates at the atomic level are all probabilities (not certainties)
and so have a pretty wide spread of actual values... hence the infamous
Schroedinger's Cat experiment.

[Dr John Stockton]

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Tue, 4
Jan 2005 17:27:34, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Dr John Stockton wrote:

JRS: In article <cr************ *******@news.de mon.co.uk>, dated Mon, 3
Jan 2005 16:31:02, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

UTC, on the other hand, is a derived
probabilisti c decay-rate measurement.

Total rubbish. It has nothing at all to do with decay rates. UTC is
based on the SI second, which is based on a precise transition of Cs-133
(see footnote [+] to my previous article), plus adjustments to make it
agree with one of the GMT-class time scales to within 0.9 seconds.

See my WWW site, and confirm by means of the links it contains; do not
trust amateur sources.

Umm - yes, it is. But as I just pointed out in one sentance exactly the
same thing I don't see your problem.

In case you are not sure why they are the same then I suggest you look
again at your description which nicely summarises that UTC is based on
decay transitions of Caesium 133 and ordered to a standardised average
(which is what the SI units are all about). Why average? Well, because
decay rates at the atomic level are all probabilities (not certainties)
and so have a pretty wide spread of actual values... hence the infamous
Schroedinger 's Cat experiment.

Obviously you have stuck in your mind a total misapprehension about the
physics of a Caesium Clock. The operation is utterly different from the
possibly so-called Atomic Clock used in archaeological carbon dating,
which is based on radioactive decay of the C14 nucleus; it is a matter
of transitions between electronic energy levels, and "decay" is not an
appropriate term.

Don't argue physics with an experienced physicist when you are not one
yourself; and, if you must do so, be careful to choose a topic which is
not so closely adjacent to his own. By adjacent, I don't just mean
similar, but literally along-the-corridor.

For further information on the physics of the Caesium Clock, consult the
NPL, NIST, and BIPM Web sites - it should be on all of them (NIST, at
least, is liable to call it Cesium). It will also be in books in the
larger public libraries.

--
© John Stockton, Surrey, UK. *@merlyn.demon. co.uk / ??*********@phy sics.org ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)