Last Comment Bug 22964 - (getYear) JavaScript: getYear returns "100" for 2000
(getYear)
: JavaScript: getYear returns "100" for 2000
Status: VERIFIED INVALID
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Nobody; OK to take it and work on it
:
Mentors:
: 23134 45764 58241 60696 65681 100123 114401 115264 129662 133435 142496 153229 155995 160532 161273 161885 162843 169766 175253 180587 187962 192241 192481 194789 201531 221627 224265 228929 233017 233092 235819 235837 236186 238030 245104 251437 251568 261399 261997 263453 267028 268361 268833 269756 270207 276567 277740 278699 278833 279128 280319 282371 288259 290230 294628 296022 306702 332349 337856 340299 342004 343382 352487 428064 443901 518574 893695 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-03 15:39 PST by job
Modified: 2013-07-15 02:59 PDT (History)
64 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
the first bit is some javascript showing right plus false year print (5.81 KB, text/html)
2000-01-03 15:43 PST, job
no flags Details

Description job 2000-01-03 15:39:07 PST
Communicator 4.51 and 4.6

This may not be the right place -
still worth checking, i would think.
Comment 1 job 2000-01-03 15:43:59 PST
Created attachment 3935 [details]
the first bit is some javascript showing right plus false year print
Comment 2 John Morrison 2000-01-03 17:59:59 PST
Note: this is not the right place for bugs in Communicator 4.x.
It is for bugs in the Mozilla codebase, which does not include the code
for Communicator 4.x. The Mozilla codebase however does include the
Javascript engine, which covers this "bug".

However, this behaviour is as designed and documented. Note that the
use of Date.getYear() was deprecated in favour of .getFullYear()
(which returns the full four-digit value for the year). Excerpts from
the documentation follow. Hope this helps. (But marking this bug
report INVALID).

----------------------------------------------------------------------
----------------------------------------------------------------------
Note: Javascript 1.3+ is implemented in Navigator 4.06 and higher

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

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

getFullYear
  Returns the year of the specified date according to local time.
    Implemented in JavaScript 1.3
    ECMA version  ECMA-262
  Description
    The value returned by getFullYear is an absolute number. For dates
    between the years 1000 and 9999, getFullYear returns a four-digit
    number, for example, 1995. Use this function to make sure a year is
    compliant with years after 2000.

    Use this method instead of the getYear method.
Comment 3 Blake Ross 2000-09-29 19:48:18 PDT
vrfy invalid
Comment 4 R.K.Aa. 2000-11-19 16:40:55 PST
*** Bug 60696 has been marked as a duplicate of this bug. ***
Comment 5 Phil Schwartau 2003-04-10 13:15:21 PDT
*** Bug 201531 has been marked as a duplicate of this bug. ***
Comment 6 Phil Schwartau 2003-10-08 16:31:26 PDT
*** Bug 221627 has been marked as a duplicate of this bug. ***
Comment 7 Charles Fenwick 2004-02-03 21:08:34 PST
*** Bug 233017 has been marked as a duplicate of this bug. ***
Comment 8 Jo Hermans 2004-02-04 15:37:20 PST
*** Bug 233092 has been marked as a duplicate of this bug. ***
Comment 9 Olivier Cahagne 2004-02-27 05:20:14 PST
*** Bug 235819 has been marked as a duplicate of this bug. ***
Comment 10 Olivier Cahagne 2004-03-19 13:47:02 PST
*** Bug 238030 has been marked as a duplicate of this bug. ***
Comment 11 Bill Mason 2004-09-28 15:52:37 PDT
*** Bug 261997 has been marked as a duplicate of this bug. ***
Comment 12 Stefan Borggraefe 2004-10-08 02:21:22 PDT
*** Bug 263453 has been marked as a duplicate of this bug. ***
Comment 13 Phil Ringnalda (:philor) 2004-10-31 08:39:04 PST
*** Bug 267028 has been marked as a duplicate of this bug. ***
Comment 14 Michiel van Leeuwen (email: mvl+moz@) 2004-11-14 03:00:55 PST
*** Bug 269756 has been marked as a duplicate of this bug. ***
Comment 15 Bill Mason 2004-11-16 10:59:24 PST
*** Bug 270207 has been marked as a duplicate of this bug. ***
Comment 16 Jo Hermans 2005-01-10 04:34:09 PST
*** Bug 277740 has been marked as a duplicate of this bug. ***
Comment 17 Doug Wright 2005-01-17 04:56:55 PST
*** Bug 278699 has been marked as a duplicate of this bug. ***
Comment 18 Erik Fabert 2005-01-18 09:22:01 PST
*** Bug 278833 has been marked as a duplicate of this bug. ***
Comment 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:12:14 PST
*** Bug 65681 has been marked as a duplicate of this bug. ***
Comment 20 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:17:09 PST
*** Bug 160532 has been marked as a duplicate of this bug. ***
Comment 21 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:17:12 PST
*** Bug 169766 has been marked as a duplicate of this bug. ***
Comment 22 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:17:18 PST
*** Bug 228929 has been marked as a duplicate of this bug. ***
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:18:38 PST
*** Bug 276567 has been marked as a duplicate of this bug. ***
Comment 24 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:20:30 PST
*** Bug 58241 has been marked as a duplicate of this bug. ***
Comment 25 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:23:39 PST
*** Bug 161885 has been marked as a duplicate of this bug. ***
Comment 26 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:23:40 PST
*** Bug 162843 has been marked as a duplicate of this bug. ***
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:23:43 PST
*** Bug 187962 has been marked as a duplicate of this bug. ***
Comment 28 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:24:38 PST
*** Bug 192241 has been marked as a duplicate of this bug. ***
Comment 29 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:24:45 PST
*** Bug 192481 has been marked as a duplicate of this bug. ***
Comment 30 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:24:47 PST
*** Bug 194789 has been marked as a duplicate of this bug. ***
Comment 31 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:25:34 PST
*** Bug 235837 has been marked as a duplicate of this bug. ***
Comment 32 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:25:48 PST
*** Bug 224265 has been marked as a duplicate of this bug. ***
Comment 33 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:25:50 PST
*** Bug 114401 has been marked as a duplicate of this bug. ***
Comment 34 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:27:02 PST
*** Bug 115264 has been marked as a duplicate of this bug. ***
Comment 35 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:27:05 PST
*** Bug 129662 has been marked as a duplicate of this bug. ***
Comment 36 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:28:35 PST
*** Bug 133435 has been marked as a duplicate of this bug. ***
Comment 37 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:28:37 PST
*** Bug 142496 has been marked as a duplicate of this bug. ***
Comment 38 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:28:52 PST
*** Bug 153229 has been marked as a duplicate of this bug. ***
Comment 39 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:29:03 PST
*** Bug 155995 has been marked as a duplicate of this bug. ***
Comment 40 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:30:17 PST
*** Bug 161273 has been marked as a duplicate of this bug. ***
Comment 41 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:30:21 PST
*** Bug 175253 has been marked as a duplicate of this bug. ***
Comment 42 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:30:31 PST
*** Bug 180587 has been marked as a duplicate of this bug. ***
Comment 43 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:31:06 PST
*** Bug 236186 has been marked as a duplicate of this bug. ***
Comment 44 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:31:34 PST
*** Bug 251437 has been marked as a duplicate of this bug. ***
Comment 45 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:32:03 PST
*** Bug 251568 has been marked as a duplicate of this bug. ***
Comment 46 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:32:37 PST
*** Bug 261399 has been marked as a duplicate of this bug. ***
Comment 47 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:32:56 PST
*** Bug 268361 has been marked as a duplicate of this bug. ***
Comment 48 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:33:04 PST
*** Bug 268833 has been marked as a duplicate of this bug. ***
Comment 49 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:33:35 PST
*** Bug 279128 has been marked as a duplicate of this bug. ***
Comment 50 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:35:56 PST
*** Bug 45764 has been marked as a duplicate of this bug. ***
Comment 51 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-23 15:37:53 PST
*** Bug 100123 has been marked as a duplicate of this bug. ***
Comment 52 Erik Fabert 2005-01-25 01:34:39 PST
*** Bug 23134 has been marked as a duplicate of this bug. ***
Comment 53 Erik Fabert 2005-01-25 02:52:51 PST
*** Bug 245104 has been marked as a duplicate of this bug. ***
Comment 54 Tony Tovar 2005-01-26 12:04:15 PST
Not to be contradictory or anything, but if you add up all the dupes associated
with this bug, then add-up all the dupes associated with the dupes, it appears
that there's still a lot of web-sites out there using this "deprecated"
javascript command.

Rather than 'blindly' maintaining the original Netscape Communicator code (for
"backwards compatibility" I know) wouldn't it be a simple change to report the
last 2-digits of the year like everyone always expected it to?  IANAP but I have
a hard time seeing how this would 'break' pre-year2000 code. $.02
Comment 55 José Jeria 2005-01-29 02:42:27 PST
*** Bug 280319 has been marked as a duplicate of this bug. ***
Comment 56 Jo Hermans 2005-02-15 13:39:06 PST
*** Bug 282371 has been marked as a duplicate of this bug. ***
Comment 57 Darien Brown 2005-02-18 18:39:50 PST
The common "expected" behaviour of this function is to return a two-digit
number. I agree with Tony Tovar that perhaps it would be best to just make it
work this way.

Many of the bug reports may be a result of Microsoft's implementation of ECMA,
which returns two digits for years in the 1900's but four digits for all other
years. This is nowhere near the official ECMA description for this function.
However, the majority of users are not aware of the ECMA standard and expect the
same behaviour across all platforms.

Changing this function to always return two digits is a healthy compromise and
should be acceptable to most users.

I haven't seen the source, but it would seem that this would be as simple as
modding the result by 100.
Comment 58 Chris 2005-02-19 15:55:10 PST
Unfortunately, another expected behaviour is to support the subtraction of one 
year date from another to calculate the intervening time.  Microsoft broke this 
as part of their Y2k policy.

Can we assume the whole world now accepts this is broken?  And will programmers 
remember this for the next 10 years?  If so, there is no real point making the 
techevangelism task harder than it needs to be.  

I vote go with the MS line and make sure in all the documentation that 
programmers do remember.
Comment 59 Darien Brown 2005-02-21 19:19:53 PST
After taking a gander at the source, I can see that the behaviour that Chris
described *is* implemented as long as the JavaScript version is specified and is
less than or equal to version 1.2. The new behaviour was added in 1.3.

Changing line 830 to read:

result = (result - 1900) % 100;

would create the behaviour that I described, but after reading Chris' proposal
and realizing that that behaviour was already there, I'm tempted to accept that
the code should not be changed at all. (Read John Morrison's comment.)

The documentation *should* be changed to point out that MS-compatible behaviour
may be achieved by using version="1.2". Anyone using JavaScript 1.3 or greater
should be using the newer getFullYear() anyway.
Comment 60 Darien Brown 2005-02-21 19:27:00 PST
Oops. I referred to a line of source and no filename. I was looking at:

mozilla/js/src/jsdate.c
Comment 61 Byron Jones ‹:glob› [PTO until 2016-10-10] 2005-03-30 00:44:12 PST
*** Bug 288259 has been marked as a duplicate of this bug. ***
Comment 62 Matthias Versen [:Matti] 2005-04-13 14:42:59 PDT
*** Bug 290230 has been marked as a duplicate of this bug. ***
Comment 63 Matthias Versen [:Matti] 2005-05-30 23:09:57 PDT
*** Bug 296022 has been marked as a duplicate of this bug. ***
Comment 64 Rotem Liss 2005-06-14 06:42:07 PDT
From EMCA-262 standard (
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf ):

"
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*.
"

Mozilla should behave as it behaves now, and IE is wrong. You should use
Date.getFullYear to get the full year.
Comment 65 Jo Hermans 2005-09-01 08:00:58 PDT
*** Bug 306702 has been marked as a duplicate of this bug. ***
Comment 66 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-12-12 12:11:02 PST
*** Bug 294628 has been marked as a duplicate of this bug. ***
Comment 67 Nickolay_Ponomarev 2006-03-31 04:14:09 PST
*** Bug 332349 has been marked as a duplicate of this bug. ***
Comment 68 Phil Ringnalda (:philor) 2006-05-13 18:31:37 PDT
*** Bug 337856 has been marked as a duplicate of this bug. ***
Comment 69 grzegorj 2006-05-14 07:23:38 PDT
There is a serious misunderstanding among Mozilla coders about this BUG. Basically, Mozilla is a tool for those who browse the Internet, and not a tool for a webmaster. The opinion that "Mozilla should behave as it behaves now, and IE is wrong. You should use Date.getFullYear to get the full year." is just stupid and nonsense, and nothing more to add. But the Mozilla user who browses the Internet CANNOT use getFullYear instead of getYear because he is not the author of the page he is browsing!!! Is it really so hard that Mozilla authors cannot understand it?

And what? Should the user (who just browses the Internet with Mozilla) somehow hack the code of the page which he is browsing only because the Mozilla coders want to obey theoretic standards which nobody obeys? (see the number of comments in this thread!) Mozilla cannot read getYear properly (= in the way which the webmaster planned) because of some stupid standard which is not obeyed by many webmasters. Why should the user suffer the consequences of it?
Comment 70 Jesse Ruderman 2006-06-04 04:14:18 PDT
*** Bug 340299 has been marked as a duplicate of this bug. ***
Comment 71 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-06-19 04:33:21 PDT
*** Bug 342004 has been marked as a duplicate of this bug. ***
Comment 72 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-07-02 00:14:43 PDT
*** Bug 343382 has been marked as a duplicate of this bug. ***
Comment 73 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-09-13 02:25:28 PDT
*** Bug 352487 has been marked as a duplicate of this bug. ***
Comment 74 Ryan Flint [:rflint] (ping via IRC for reviews) 2007-09-13 11:18:19 PDT
*** Bug 396060 has been marked as a duplicate of this bug. ***
Comment 75 Aiko 2008-04-09 13:29:44 PDT
*** Bug 428064 has been marked as a duplicate of this bug. ***
Comment 76 Dave Townsend [:mossop] 2008-07-07 06:51:00 PDT
*** Bug 443901 has been marked as a duplicate of this bug. ***
Comment 77 Dave Townsend [:mossop] 2008-07-07 06:54:06 PDT
*** Bug 443901 has been marked as a duplicate of this bug. ***
Comment 78 Matthias Versen [:Matti] 2009-09-24 17:40:17 PDT
*** Bug 518574 has been marked as a duplicate of this bug. ***
Comment 79 Mardeg 2013-07-15 02:59:43 PDT
*** Bug 893695 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.