Closed Bug 22964 (getYear) Opened 25 years ago Closed 25 years ago

JavaScript: getYear returns "100" for 2000

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: job, Unassigned)

References

Details

Attachments

(1 file)

the first bit is some javascript showing right plus false year print
5.81 KB, text/html
Details
Communicator 4.51 and 4.6 This may not be the right place - still worth checking, i would think.
Component: Misc → Javascript Engine
Product: Architecture → Browser
Version: 5.0 → other
Status: NEW → RESOLVED
Closed: 25 years ago
QA Contact: nobody → rginda
Resolution: --- → INVALID
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.
vrfy invalid
Status: RESOLVED → VERIFIED
*** Bug 60696 has been marked as a duplicate of this bug. ***
*** Bug 201531 has been marked as a duplicate of this bug. ***
*** Bug 221627 has been marked as a duplicate of this bug. ***
*** Bug 233017 has been marked as a duplicate of this bug. ***
*** Bug 233092 has been marked as a duplicate of this bug. ***
*** Bug 235819 has been marked as a duplicate of this bug. ***
*** Bug 238030 has been marked as a duplicate of this bug. ***
*** Bug 261997 has been marked as a duplicate of this bug. ***
*** Bug 263453 has been marked as a duplicate of this bug. ***
*** Bug 267028 has been marked as a duplicate of this bug. ***
*** Bug 269756 has been marked as a duplicate of this bug. ***
*** Bug 270207 has been marked as a duplicate of this bug. ***
Alias: getYear
OS: Linux → All
Priority: P3 → --
Hardware: PC → All
*** Bug 277740 has been marked as a duplicate of this bug. ***
*** Bug 278699 has been marked as a duplicate of this bug. ***
*** Bug 278833 has been marked as a duplicate of this bug. ***
*** Bug 65681 has been marked as a duplicate of this bug. ***
*** Bug 160532 has been marked as a duplicate of this bug. ***
*** Bug 169766 has been marked as a duplicate of this bug. ***
*** Bug 228929 has been marked as a duplicate of this bug. ***
*** Bug 276567 has been marked as a duplicate of this bug. ***
*** Bug 58241 has been marked as a duplicate of this bug. ***
*** Bug 161885 has been marked as a duplicate of this bug. ***
*** Bug 162843 has been marked as a duplicate of this bug. ***
*** Bug 187962 has been marked as a duplicate of this bug. ***
*** Bug 192241 has been marked as a duplicate of this bug. ***
*** Bug 192481 has been marked as a duplicate of this bug. ***
*** Bug 194789 has been marked as a duplicate of this bug. ***
*** Bug 235837 has been marked as a duplicate of this bug. ***
*** Bug 224265 has been marked as a duplicate of this bug. ***
*** Bug 114401 has been marked as a duplicate of this bug. ***
*** Bug 115264 has been marked as a duplicate of this bug. ***
*** Bug 129662 has been marked as a duplicate of this bug. ***
*** Bug 133435 has been marked as a duplicate of this bug. ***
*** Bug 142496 has been marked as a duplicate of this bug. ***
*** Bug 153229 has been marked as a duplicate of this bug. ***
*** Bug 155995 has been marked as a duplicate of this bug. ***
*** Bug 161273 has been marked as a duplicate of this bug. ***
*** Bug 175253 has been marked as a duplicate of this bug. ***
*** Bug 180587 has been marked as a duplicate of this bug. ***
*** Bug 236186 has been marked as a duplicate of this bug. ***
*** Bug 251437 has been marked as a duplicate of this bug. ***
*** Bug 251568 has been marked as a duplicate of this bug. ***
*** Bug 261399 has been marked as a duplicate of this bug. ***
*** Bug 268361 has been marked as a duplicate of this bug. ***
*** Bug 268833 has been marked as a duplicate of this bug. ***
*** Bug 279128 has been marked as a duplicate of this bug. ***
*** Bug 45764 has been marked as a duplicate of this bug. ***
*** Bug 100123 has been marked as a duplicate of this bug. ***
QA Contact: rginda → nobody
*** Bug 23134 has been marked as a duplicate of this bug. ***
*** Bug 245104 has been marked as a duplicate of this bug. ***
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
*** Bug 280319 has been marked as a duplicate of this bug. ***
*** Bug 282371 has been marked as a duplicate of this bug. ***
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.
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.
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.
Oops. I referred to a line of source and no filename. I was looking at: mozilla/js/src/jsdate.c
*** Bug 288259 has been marked as a duplicate of this bug. ***
*** Bug 290230 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 296022 has been marked as a duplicate of this bug. ***
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.
*** Bug 306702 has been marked as a duplicate of this bug. ***
*** Bug 294628 has been marked as a duplicate of this bug. ***
*** Bug 332349 has been marked as a duplicate of this bug. ***
*** Bug 337856 has been marked as a duplicate of this bug. ***
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?
*** Bug 340299 has been marked as a duplicate of this bug. ***
*** Bug 342004 has been marked as a duplicate of this bug. ***
*** Bug 343382 has been marked as a duplicate of this bug. ***
*** Bug 352487 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.

Attachment

General

Creator:
Created:
Updated:
Size: