Closed Bug 82354 Opened 24 years ago Closed 24 years ago

Implementation of Date.getYear() does not comply with definition.

Categories

(Core :: JavaScript Engine, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: dkh2, Assigned: rogerl)

References

()

Details

Implementation of the Date.getYear() method does not comply with its definition
(http://developer.netscape.com/docs/manuals/js/client/jsref/date.htm#1193137).
This problem has existed since at least NS4.7 and continues today.  A parallel
bug report will be filed with Netscape.

According to documentation the Date value is stored as the number milliseconds
since 1970. The getYear() method should return the number of calendar years
since 1970.  In fact, it returns the number of calendar years since 1900.

Thus, this code:
<script type="text/javascript" language="javascript">
<!--
var today = new Date();
document.write(today.getYear());
//-->
</script>

If run during the year 2001 will write the value "101" to a Netscape or Mozilla
screen. According to documentation, the correct value should be 31. An
acceptable alternative would be to return the actual year value of 2001 and to
update documentation to match.

Differences from other implementations: The Microsoft implementation of the
getYear() method in IE returns the number of years since the beginning of the
Christian era.  Hence, this year the IE implementation returns 2001.

The sample code above writes the value 2001 to an IE screen.

The problem is replicated in Mozilla (Build ID: 2001031614) on Linux, and in
Opera 5.0 on Linux, as well as Mozilla (Build ID: 2001050515) on Windows NT,
Netscape 6.0 {Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010131
Netscape6/6.01}, and Netscape Communicator 4.75 on Windows NT.
From the docs:

"The getYear method returns the year minus 1900;"

It is not supposed to return the number of calendar year since 1970.
From the ECMA-262 standard:

B.2.4 Date.prototype.getYear() 
NOTE: The getFullYear method is preferred for nearly all purposes, 
      because it avoids the “year 2000 problem.” 

When the getYear method is called with no arguments the following steps 
are taken: 

1. Let t be this time value. 
2. If t is NaN, return NaN. 
3. Return YearFromTime(LocalTime(t)) - 1900.
From Netscape docs:

http://developer.netscape.com/docs/manuals/js/core/jsref/date.htm#1194138

getYear
  Returns the year in the specified date according to local time.
    JavaScript 1.3: deprecated; also, getYear returns the year minus
    1900 regardless of the year specified
    ECMA version ECMA-262

  Description
    getYear is no longer used and has been replaced by the getFullYear
    method.

    The getYear method returns the year minus 1900; thus:

      For years above 2000, the value returned by getYear is 100 or
      greater. For example, if the year is 2026, getYear returns 126.

      For years between and including 1900 and 1999, the value returned
      by getYear is between 0 and 99. For example, if the year is 1976,
      getYear returns 76.

      For years less than 1900 or greater than 1999, the value returned
      by getYear is less than 0. For example, if the year is 1800,
      getYear returns -100.

      To take into account years before and after 2000, you should use
      Date.getFullYear instead of getYear so that the year is specified
      in full.
I'm afraid I have to mark this one as Invalid, but thank you for this report.
We depend on contributors like to to catch the things we miss! 
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Marking Verified - 
Status: RESOLVED → VERIFIED
Recommendation:

Javascript documentation at http://developer.netscape.com/ is badly out of 
date. This and other now obsolete methods are still being presented as current.

Javascript documentation at http://developer.netscape.com/ MUST be updated to 
current coding standards to be useful to developers in the field.
You are absolutely right. cc'ing Steve Rudman re this issue - 
*** Bug 294648 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.