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.toGMTString();
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

[Lee]

clintonG said:

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.toGMTString();
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.

Are you sure it shows the time as 19:54:18?
At that time CST it *is* the next day in GMT.

[clintonG]

Thank you for your attention. We can scratch that time for now noting the
discrepancy may be because I copied and pasted to make things easier to read
but read or run the following please...

//Example A
//Returns: Sun Dec 26 2004 10:49:25 GMT-0600 (Central Standard Time)
var expDate = new Date( );
document.write("expDate: " + expDate + "<br />");
//Example B
//Returns: Sun, 26 Dec 2004 16:49:25 GMT
var today = new Date( );
var myDateString = today.toGMTString( );
document.write("myDateString: " + myDateString);

I understand what is going on now. Example A uses the Date method that
returns time as CST which is GMT-0600 hours (6 hours less than GMT) so
sitting in front of a computer in a region that uses CST (me) and running
Example B at a time of day less than 6 hours from midnight in Greenwich will
indicate the date as the 'next day' when the the Date( ) method is overriden
by the toGMTString( ) method.

<%= Clinton Gallagher


"Lee" <RE**************@cox.net> wrote in message
news:cq*********@drn.newsguy.com...

clintonG said:

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

var today = new Date();
var GMTDate = today.toGMTString();
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.

Are you sure it shows the time as 19:54:18?
At that time CST it *is* the next day in GMT.

[Michael Winter]

On Sun, 26 Dec 2004 11:03:47 -0600, clintonG
<cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote:

[snip]

var today = new Date( );
var myDateString = today.toGMTString( );

Just so you know, the toGMTString method is deprecated in favour of the
toUTCString method. The effect if the same, though.

[snip]

Mike
Please don't top-post.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[clintonG]

Thank you. I'll try that out right now...

<%= Clinton Gallagher

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:opsjmlj2uox13kvk@atlantis...

On Sun, 26 Dec 2004 11:03:47 -0600, clintonG
<cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote:

[snip]

var today = new Date( );
var myDateString = today.toGMTString( );

Just so you know, the toGMTString method is deprecated in favour of the
toUTCString method. The effect if the same, though.

[snip]

Mike
Please don't top-post.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[clintonG]

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.

var today = new Date();
var UTCDateTime = today.toUTCString();
document.write("<b>UTCDateTime: </b>" + UTCDateTime);

<%= Clinton Gallagher
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:opsjmlj2uox13kvk@atlantis...

On Sun, 26 Dec 2004 11:03:47 -0600, clintonG
<cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote:

[snip]

var today = new Date( );
var myDateString = today.toGMTString( );

Just so you know, the toGMTString method is deprecated in favour of the
toUTCString method. The effect if the same, though.

[snip]

Mike
Please don't top-post.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Michael Winter]

On Sun, 26 Dec 2004 20:20:47 GMT, clintonG
<cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote:

Please don't top-post.

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 the method:

"This function returns a string value. The contents of the string
are implementation-dependent, but are intended to represent the
Date in a convenient, human-readable form in UTC."

-- Section 15.9.5.42, ECMA-262

If you need a specific format, it's best to do it yourself.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Lee]

clintonG said:

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.

Welcome to the newsgroup.

Referring to popular browsers as "Firefraud" or "Netscrape", etc is not really a
good way to ensure your popularity or that you will receive the best possible
answers to your questions. You're sure to piss off a few and make a few more
write you off as a childish twit.

Pointing out that IE "makes the trains run on time" isn't going to change many
opinions, anyway.

[Mark Preston]

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.

[Dr John Stockton]

JRS: In article <R%********************@twister.rdc-kc.rr.com>, dated
Sun, 26 Dec 2004 04:22:09, seen in news:comp.lang.javascript, clintonG
<cs*********@REMOVETHISTEXTmetromilwaukee.com> posted :

When the following code is run on Sat Dec 25 2004 19:54:18 GMT-0600 (Central
Standard Time)
Please note that this is an international newsgroup. Terms such as
"Central Standard Time" are therefore not generally helpful, since we do
not know of what it might be the centre. Russia? Australia?
var today = new Date();
var GMTDate = today.toGMTString();
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.

There is something wrong with your system or its operator.
Note : this response to your article is formatted in accordance with
standard usenet recommendations endorsed by the Wednesday edition of the
FAQ (which you should have read) of this newsgroup.

Note : Americans, and the software that they originate, traditionally
have a very poor understanding of date and time, except as it applies in
CONUS, maybe AK & HI, and just possibly CA (the region which prevents AK
from being an island). It is not only non-Americans that need to allow
for that.

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

[Dr John Stockton]

JRS: In article <cq*******************@news.demon.co.uk>, dated Tue, 28
Dec 2004 16:05:17, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.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().toGMTString() -> Tue, 28 Dec 2004 20:42:52 UTC
new Date().toUTCString() -> Tue, 28 Dec 2004 20:43:28 UTC
new Date().toLocaleString() -> 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.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.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****@nosource.co.uk> wrote in message
news:cr*******************@news.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.demon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.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.

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.demon.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.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.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.demon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.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.demon.co.uk>, dated Mon, 3
Jan 2005 16:31:02, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.co.uk> posted :

Dr John Stockton wrote:

JRS: In article <cr*******************@news.demon.co.uk>, dated Fri, 31
Dec 2004 12:22:24, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.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.

Approximately correct.
UTC, on the other hand, is a derived
probabilistic 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 / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.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.demon.co.uk>, dated Mon, 3
Jan 2005 16:31:02, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.co.uk> posted :

UTC, on the other hand, is a derived
probabilistic 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.demon.co.uk>, dated Tue, 4
Jan 2005 17:27:34, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.co.uk> posted :

Dr John Stockton wrote:

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

UTC, on the other hand, is a derived
probabilistic 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 / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.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)