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>

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Tue, 7 Jun 2005 03:54:01, seen in (e-mail address removed) 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() .

 

[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]

When asking date questions, always give your true whereabouts [...]

I apologise. I am located in India.

Your timezone would normally be helpful, too. It doesn't matter in this
case, though.

[...] 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?

The Date constructor creates a local time value. When you create the
date set to midnight, it's still the previous day for everyone west of
you, including those at +0000.

If you want to create a Date object that is set in terms of UTC, you
need to take a slightly indirect route when create the object.

First, call the static UTC method like the Date constructor:

var ms = Date.UTC(2004, 0, 1);

This returns a millisecond value that corresponds to the UTC time. You
can now call the Date constructor using this value to create the Date
object:

var date = new Date(ms);

[snip]

Mike

 

[Michael Winter]

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

 

[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]

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]

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

 

[VK]

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]

[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

 

[John W. Kennedy]

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




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 G Harris]

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

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 8 Jun 2005 00:08:58, seen in (e-mail address removed) posted :

I apologise. I am located in India.


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.

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Wed, 8 Jun 2005 05:00:33, seen in VK

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, ...)) .

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Wed, 8 Jun 2005 12:07:30, seen in

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

 

[Michael Winter]

JRS: In article <[email protected]>,
dated Wed, 8 Jun 2005 12:07:30, seen in Michael Winter <[email protected]> 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

 

[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 <[email protected]>
, dated Thu, 9 Jun 2005 04:32:29, seen in VK

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.