getUTCFullYear returns wrong info for 1st Jan????

[rithish]

<code>
var dt = new Date(2004, 0, 1);
alert ( dt.getDate() ); // returns proper date
alert ( dt.getUTCFullYear() ); // returns 2003
</code>

Why is this so? Or is that I am missing something?

Regards,
Rithish.

[VK]

> Or is that I am missing something?

You are missing the time zone difference. When people are already
drinking New Year champaign in your location, people in Greenwich just
putting it in the cooler :-)

(Greenwich Mean Time = GMT = UTC)

[Evertjan.]

wrote on 07 jun 2005 in comp.lang.javascript:

<code>
var dt = new Date(2004, 0, 1);
alert ( dt.getDate() ); // returns proper date
alert ( dt.getUTCFullYear() ); // returns 2003
</code>

is that I am missing something?
yes
Why is this so?

<script type="text/JavaScript">

var dt = new Date(2004, 0, 1); // enter local date
alert ( dt.getDate() ); // returns proper LOCAL date
alert ( dt.getFullYear() ); // returns LOCAL year
alert ( dt.getUTCDate() ); // returns proper UTC date
alert ( dt.getUTCFullYear() ); // returns UTC year

</script>

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Dr John Stockton]

JRS: In article <11*********************@g14g2000cwa.googlegroups. com>,
dated Tue, 7 Jun 2005 03:54:01, seen in news:comp.lang.javascript,
ri*****@gmail.com posted :

<code>
var dt = new Date(2004, 0, 1);
alert ( dt.getDate() ); // returns proper date
alert ( dt.getUTCFullYear() ); // returns 2003
</code>

Why is this so? Or is that I am missing something?

When asking date questions, always give your true whereabouts; it often
matters. Google unwisely puts a US PDT datestamp.

I deduce that your system is localised for the Old World (but not the
UK, Ireland, Portugal, Iceland, NW Africa), since your civil clock (in
January) is running ahead of GMT/UTC.

For the local Gregorian year, use getFullYear() .

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[rithish]

> When asking date questions, always give your true whereabouts; it often

matters. Google unwisely puts a US PDT datestamp.
I apologise. I am located in India.
I deduce that your system is localised for the Old World (but not the
UK, Ireland, Portugal, Iceland, NW Africa), since your civil clock (in
January) is running ahead of GMT/UTC.
I definitely am missing something. Can someone please elaborate, or
point to some information locations? How is it that only for the 1st
of Jan, getUTCFullYear() returns the previous year, and not for any
other date?
For the local Gregorian year, use getFullYear() .

If the script runs on the client-side, getFullYear() would return the
year depending on the time-settings of the client computer. Would it
not? This would again be undesirable.

Thanks again for all your responses.

Regards,
Rithish.

[VK]

OK, very slow now: do you remember New Year 2000 celebration? (or any
other New Year, but that one was the most memorizing by far). Did the
whole Earth celebrate it at the same time? No. New Year comes first to
some little island in the Pacific, then to Japan, then to China, then
to *India*, long time after to Europe, long time after to America.

So when it's already 00:00 January 01 of 2000 in New Delhi, it's still
only 8:30pm of New Year eve (Dec.31) in London.
To have some way to indicate an absolute time point, it was decided to
count the time of Royal Observatory in Greenwich (a suburb of London)
as a starting point. Then the time in any other location can be
presented as Greenwich time +/- timezone offset. For example for New
Delhi currently it's Greenwich Mean Time (GMT) + 5h 30min

So on each computer there are two virtual clocks ticking: one showing
real local time (getDate() other showing current time in Greenwich
(London, Great Britany) - getUTCDate()

It was for years people used GMT + timezone offset notation for
different purposes. But not long ago a bunch of bored idiots put a
request to ISO claiming that the term GMT (Greenwich Mean Time) reminds
of the colonial past of British Empire and blah-blah. A bunch of other
idiots in ISO did not send them to hell but introduced the term UTC
(Universal Time Coodinates) as a substitution.

So UTC is nothing but "politically correct" form of GMT. :-)

Please tell me if you are still missing something.

[Michael Winter]

On 08/06/2005 11:02, VK wrote:

OK, very slow now: [...]
Don't be so patronising, particularly if you're not going to answer the
OP's question.

[snip]
So UTC is nothing but "politically correct" form of GMT. :-)

Wrong. As I recall, UTC has a particular measuring system that differs
slightly from normal, meaning that UTC and GMT are not exactly equal.
I'm sure Dr Stockton can explain, or point to, the differences.

[snip]

Mike

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

[VK]

> Don't be so patronising
I'm not at all! But if a person refuses to accept the fact that the New
Year comes to India and to Britain at a different time, can I allow a
little smily in my overall totally polit responce? But sorry to OP if I
shouldn't do it.
the answer for OP is:
dateObject.getFullYear() gives you the current year on the computer
running your script.
dateObject.getUTCFullYear() gives you the current year in Greenwich
(London, GB).
Whether you like it or not every New Year Eve these two values will not
match each other for the period of time dateObject.getTimezoneOffset();

Wrong. As I recall, UTC has a particular measuring system

Skiping "about.com"-style sources: maybe you believe to US Army?
<http://aa.usno.navy.mil/faq/docs/UT.html>
Skip the "atomic clock" fog they put in there. You may think that Her
Magesty Greenwich Royal Observatory is still using telescopes and
logarithm rulers to calculate the time. It's all damn "polical
correctness" and national ambitions.

As the last proof compare the Date() specs for JavaScript 1.0 and for
the last one,
also compare first d.toGMTString() and d.toUTCString(), and then read
how "bad and obsolete" toGMTString() is in all specs.

[Michael Winter]

On 08/06/2005 13:00, VK wrote:

Don't be so patronising

I'm not at all! But if a person refuses to accept the fact that the New
Year comes to India and to Britain at a different time

As I see it, that wasn't the issue at all, which was why I said you
weren't answering the question. I don't think the OP understood that the
Date constructor created a local-time Date object, which was why
Date.prototype.getUTCFullYear wasn't returning the year used in the
constructor.

[snip]

Wrong. As I recall, UTC has a particular measuring system

Skiping "about.com"-style sources: maybe you believe to US Army?
<http://aa.usno.navy.mil/faq/docs/UT.html>

UT is different from UTC. Read the article again.

[snip]

Mike

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

[VK]

>> <http://aa.usno.navy.mil/faq/do*cs/UT.html>

UT is different from UTC. Read the article again.

"The times of various events, particularly astronomical and weather
phenomena, are often given in "Universal Time" (abbreviated UT) which
is sometimes referred to, now colloquially, as "Greenwich Mean Time"
(abbreviated GMT). "
....
"However, in the most common civil usage, UT refers to a time scale
called "Coordinated Universal Time" (abbreviated UTC), which is the
basis for the worldwide system of civil time."

^ a = b = c = ... = x really comes to a = x

"Greenwich Mean Time is a widely used historical term, but one that has
been used in several ways."
Oh really? Like what?
"Because of the ambiguity, its use is no longer recommended in
technical contexts."
No, it's because only US Navy have REAL EXACT time now, and they are
being so generous to share it with the world :-)

[Michael Winter]

On 08/06/2005 13:35, VK wrote:

<http://aa.usno.navy.mil/faq/do*cs/UT.html>

UT is different from UTC. Read the article again.

[snipped quotes and babble]

You failed to quote the part that states there are several different
definitions of Universal Time.

Defining time in ways that make no reference GMT has nothing to do with
political correctness, but just a desire to be unambiguous. If you need
accuracy, you cannot use a colloquial term that might mean different
things to different people.

Mike

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

[John W. Kennedy]

VK wrote:

Don't be so patronising

I'm not at all! But if a person refuses to accept the fact that the New
Year comes to India and to Britain at a different time, can I allow a
little smily in my overall totally polit responce? But sorry to OP if I
shouldn't do it.
the answer for OP is:
dateObject.getFullYear() gives you the current year on the computer
running your script.
dateObject.getUTCFullYear() gives you the current year in Greenwich
(London, GB).
Whether you like it or not every New Year Eve these two values will not
match each other for the period of time dateObject.getTimezoneOffset();

Wrong. As I recall, UTC has a particular measuring system

Skiping "about.com"-style sources: maybe you believe to US Army?
<http://aa.usno.navy.mil/faq/docs/UT.html>
Skip the "atomic clock" fog they put in there.

*PLONK*
--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich have
always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"

[John G Harris]

In article <11**********************@g47g2000cwa.googlegroups .com>, VK
<sc**********@yahoo.com> writes

<snip>

It was for years people used GMT + timezone offset notation for
different purposes. But not long ago a bunch of bored idiots put a
request to ISO claiming that the term GMT (Greenwich Mean Time) reminds
of the colonial past of British Empire and blah-blah. A bunch of other
idiots in ISO did not send them to hell but introduced the term UTC
(Universal Time Coodinates) as a substitution.

So UTC is nothing but "politically correct" form of GMT. :-)

GMT uses the earth as a clock. UTC uses itsy bitsy electrons whizzing
around inside atoms as a clock. They're different, but not enough to
worry about if you just want to know if the pubs are open.

It's called GMT because it's at Greenwich, it's an average (mean), and
it's a time. Nothing to do with empires.

There's a technically accurate write-up at the NPL site :
<URL:http://www.npl.co.uk/npl/ctm/time_scales.html>

John
--
John Harris

[Dr John Stockton]

JRS: In article <11**********************@z14g2000cwz.googlegroups .com>
, dated Wed, 8 Jun 2005 00:08:58, seen in news:comp.lang.javascript,
ri*****@gmail.com posted :

When asking date questions, always give your true whereabouts; it often
matters. Google unwisely puts a US PDT datestamp.

I apologise. I am located in India.

I deduce that your system is localised for the Old World (but not the
UK, Ireland, Portugal, Iceland, NW Africa), since your civil clock (in
January) is running ahead of GMT/UTC.

I definitely am missing something. Can someone please elaborate, or
point to some information locations? How is it that only for the 1st
of Jan, getUTCFullYear() returns the previous year, and not for any
other date?

Because India is only 5.5 hours ahead of GMT. And there is therefore a
difference only for times within the first 5.5 hours of the Indian
Gregorian year.

Note that there is a difference for the UK in Summer, when local time is
an hour ahead of GMT.

For the local Gregorian year, use getFullYear() .

If the script runs on the client-side, getFullYear() would return the
year depending on the time-settings of the client computer. Would it
not? This would again be undesirable.

That is not undesirable; that is its purpose. The UTC functions are
provided for getting a "world standard" time, give or take client
machine setting error.

More via below.

--
© 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 <11*********************@z14g2000cwz.googlegroups. com>,
dated Wed, 8 Jun 2005 05:00:33, seen in news:comp.lang.javascript, VK
<sc**********@yahoo.com> posted :

the answer for OP is:
dateObject.getFullYear() gives you the current year on the computer
running your script.
dateObject.getUTCFullYear() gives you the current year in Greenwich
(London, GB).
Whether you like it or not every New Year Eve these two values will not
match each other for the period of time dateObject.getTimezoneOffset();

No, that happens in chronologically retarded locations like the USA.
In chronologically advanced locations like India it happens on New
Year's Day.

And your description is accurate only for the OP's case, of dateObject
being set by new Date().

Javascript had new Date(Y, M', D, ...) from the beginning, I
suppose, and used local time as being a common requirement. It is a
pity that when the UTC functions were introduced they did not feel able
to add new UTCDate(y; m', d, ...) - one must, IIRC, use
new Date(Date.UTC(y, m', d, ...)) .

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Dr John Stockton]

JRS: In article <6c******************@text.news.blueyonder.co.uk >,
dated Wed, 8 Jun 2005 12:07:30, seen in news:comp.lang.javascript,
Michael Winter <m.******@blueyonder.co.invalid> posted :

On 08/06/2005 13:00, VK wrote:

Don't be so patronising
I'm not at all! But if a person refuses to accept the fact that the New
Year comes to India and to Britain at a different time

As I see it, that wasn't the issue at all, which was why I said you
weren't answering the question. I don't think the OP understood that the
Date constructor created a local-time Date object, which was why
Date.prototype.getUTCFullYear wasn't returning the year used in the
constructor.

That could be deceptive wording. Date Objects are fundamentally UTC
(valueOf() gives UTC ms); my belief is that they probably know nothing
of the corresponding local time, but know how to ask the OS or browser
when they need the information.

The constructor constructs an object with a UTC ms value, using
parameters in Local Time.

The Object has methods for returning information both in UTC and in
Local Time.

Note that my tests show that the UTC functions are substantially faster
than the non-UTC ones; so where the work is using "calendar time"
rather than "clock time" it may be worth using the UTC functions.
I wonder - if one constructs a current Date Object in the UK, where it
is now Summer, then sets the computer to Casablanca (where there is no
Summer Time), Detroit (where time is delayed) or Sydney, then uses the
UTC and civil methods on the Object, what does one see? Does the object
use the setting at the time of interrogation, or at the time of its
creation, or what? - with due consideration of the time the computer
actually shows.

ISTM that would be an interesting and potentially useless piece of
knowledge.
UT is different from UTC. Read the article again.

Someone, IIRC, suggested that I might explain the exact difference
between time scales. I decline; but there are links on my site. Be
careful to trust only the sites of respected time-standards
organisations.

However, javascript does NOT use UTC, it only claims to. UTC has Leap
Seconds, and javascript does not.

The closest presently-defined time scale to the GMT of, say, AD 1950 is,
I've been told, UT. However, that looks like a typo for UTC.

I prefer to use, in javascript, the term GMT; except for special cases,
a small computer generally has a larger time error that the difference
between GMT ans any other "scientific" scale.

But be aware that GMT was different; before 1925, it started at the
following Noon (before mid-Oct 1805, RN time started the previous Noon).

--
© 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.

[Michael Winter]

On 08/06/2005 23:13, Dr John Stockton wrote:

JRS: In article <6c******************@text.news.blueyonder.co.uk >,
dated Wed, 8 Jun 2005 12:07:30, seen in news:comp.lang.javascript,
Michael Winter <m.******@blueyonder.co.invalid> posted :

[snip]

[...] I don't think the OP understood that the Date constructor
created a local-time Date object, which was why
Date.prototype.getUTCFullYear wasn't returning the year used in the
constructor.

That could be deceptive wording. [...]

You're right - it is. Thank you for offering a clarification.

[snip]

Mike

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

[VK]

> my belief is that they probably know nothing of the corresponding local time

This computer clock is counting milliseconds passed in *your location*
since 00:00 Jan 01 1970 until now. So if you'd leave your clock set to
zero at 00:00 Jan 01 1970 and come back now, that will be the value
you'd see.

Also through the getTimezoneOffset() JavaScript gets from the OS:
1) the time difference in minutes between your location and Greenwinch
(London).
2) you position (west/east) relative Greenwich indicated by the
getTimezoneOffset() return value sign (-/+)

These are only two pieces of info JavaScript really gets. All other
get's are internal calculations based on these two values.

This also answers you question about light-saving differences: it will
still work properly because it will be adjusted by the OS in the
getTimezoneOffset() return value.

Conclusion would be:
People *mostly* accepts the fact that when if it's daytime here, it's
nightime on the other side of the globe. But people still have
difficulties to accepts the fact that when if it's New Year here, it's
still previous year just 16 degrees to the west. Or it's Feb 01 here,
but still Jan 31 there etc. etc.

[Dr John Stockton]

JRS: In article <11**********************@g43g2000cwa.googlegroups .com>
, dated Thu, 9 Jun 2005 04:32:29, seen in news:comp.lang.javascript, VK
<sc**********@yahoo.com> posted :

This computer clock is counting milliseconds passed in *your location*
since 00:00 Jan 01 1970 until now. So if you'd leave your clock set to
zero at 00:00 Jan 01 1970 and come back now, that will be the value
you'd see.
It is not, except for countries that had their clocks set to GMT at
1970-01-01.0. The UK was not one of them (how about Ireland?).

As a script-writer, one does not know what intervals the actual clock is
counting, since it is in the OS and not in javascript proper; likewise
one does not know its origin.

In my machine the clock counts from midnight at 18.2Hz to 0x1800B0, when
it goes to zero and sets a day-carry bit for the software day-count, for
which 1980-01-01 = Day 0. It will be different for others.

Javascript new Date() performs an OS call, and converts that to
milliseconds from GMT 1970.0. The "GMT" is important; the origin of the
apparent count does not depend on user localisation. Generally, the
values change in steps of 10 ms, or 15/16 ms, or 50/60 ms (/ is or), but
there may be other figures.

Also through the getTimezoneOffset() JavaScript gets from the OS:
1) the time difference in minutes between your location and Greenwinch
(London).

You must distinguish between the time at Greenwich and Greenwich Mean
Time; for more than half a year, they differ by one hour.

--
© 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.

[Thomas 'PointedEars' Lahn]

VK wrote:

(Greenwich Mean Time = GMT = UTC)

No, read <http://en.wikipedia.org/wiki/UTC>.
PointedEars

[Dr John Stockton]

JRS: In article <uM******************@text.news.blueyonder.co.uk >,
dated Wed, 8 Jun 2005 13:54:34, seen in news:comp.lang.javascript,
Michael Winter <m.******@blueyonder.co.invalid> posted :

On 08/06/2005 13:35, VK wrote:

<http://aa.usno.navy.mil/faq/do*cs/UT.html>

UT is different from UTC. Read the article again.

[snipped quotes and babble]

You failed to quote the part that states there are several different
definitions of Universal Time.

I missed seeing that before.

There is only one current and correct definition of UT, whatever USNO
has to say on the subject.

UT0 is defined, and may match UT, I forget; UT1, UT2 and UTC are also
defined.

--
© 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 <25****************@PointedEars.de>, dated Thu, 16 Jun
2005 21:02:38, seen in news:comp.lang.javascript, Thomas 'PointedEars'
Lahn <Po*********@web.de> posted :

VK wrote:

(Greenwich Mean Time = GMT = UTC)

No, read <http://en.wikipedia.org/wiki/UTC>.

Once more, Pooh, you are stupidly answering an old article in respect of
a point which is already adequately covered in subsequent discussion.

While that wiki article may well be right, I doubt whether you are truly
qualified to judge its reliability; it would be far better to cite an
authoritative professionally-relevant institution - NPL, NIST, BIH,
USNO, NRC, or suchlike. Or, I suppose, PTB.

I do know that de.wiki has an article which links to a page of mine, but
the article is in error on a point which my page both explains and
demonstrates. When I last looked, the corresponding en.wiki page said
very little, omitting the point in question. Amateur sources should not
be relied on for technical material (well, that's true for professional
sources too; but they are usually better).

You should have noted, too, that in Javascript UTC and GMT are treated
as synonymous, and that Javascript time is *not* UTC.

--
© 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.

[Michael Winter]

On 17/06/2005 13:33, Dr John Stockton wrote:

JRS: In article <uM******************@text.news.blueyonder.co.uk >,
dated Wed, 8 Jun 2005 13:54:34, seen in news:comp.lang.javascript,
Michael Winter <m.******@blueyonder.co.invalid> posted :
[snip]

[VK] failed to quote the part that states there are several
different definitions of Universal Time.

[snip]
There is only one current and correct definition of UT, whatever USNO
has to say on the subject.
I think this too falls under 'deceptive wording'.
UT0 is defined, and may match UT, I forget; UT1, UT2 and UTC are also
defined.

I was referring to the existence of UT0, UT1, UT2 and others, rather
than just UT. Perhaps using the word 'variations' in place of 'different
definitions' would have been clearer.

Mike

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

[Thomas 'PointedEars' Lahn]

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn [...] posted :

VK wrote:

(Greenwich Mean Time = GMT = UTC)

No, read <http://en.wikipedia.org/wiki/UTC>.

Once more, Pooh, you are stupidly answering an old article in respect of
a point which is already adequately covered in subsequent discussion.
[flame]

Get a life.
PointedEars