Is your Web browser Y2K compliant? The answer may surprise you

It may seem that the millennium bug is most likely to bite 25-year-old legacy applications written in Cobol. But the fact is today's cutting-edge Internet technology is not immune to Year 2000 malaise. Ambiguities in Netscape's JavaScript and in Microsoft's JScript can create situations where dates after Dec. 31, 1999, may not work consistently. As an added bonus, dates prior to 1970 can create problems as well - an indication that the World Wide Web is indeed a place for the young.

It may seem that the millennium bug is most likely to bite 25-year-old legacy applications written in Cobol. But the fact is today's cutting-edge Internet technology is not immune to Year 2000 malaise.

Ambiguities in Netscape's JavaScript and in Microsoft's JScript can create situations where dates after Dec. 31, 1999, may not work consistently. As an added bonus, dates prior to 1970 can create problems as well - an indication that the World Wide Web is indeed a place for the young.

According to both Microsoft and Netscape, the recently announced ECMAScript standard will allow them to address these problems in the next revisions of their browsers. But the solution to the problem will still involve modifying existing JavaScripts that perform operations on the year in a date object, meaning that those with JavaScript code may have to check it for Year 2000 compliance and correct bad code.

Clearly, most developers will not find this as daunting a task as bringing 100 million lines of Cobol into Year 2000 compliance, but it is an issue that needs to be addressed.

The InfoWorld Test Center tested date objects in JavaScript in Netscape's and Microsoft's browsers and found inconsistencies in the documentation and implementation of the scripting language.

According to Netscape's online documentation for JavaScript 1.1, the date object stores "dates internally as the number of milliseconds since January 1, 1970 00:00:00," which is referred to as the epoch. It goes on to say that "dates prior to 1970 are not allowed."

The Netscape documentation also refers to several date-related methods including getYear, which "returns the year in the specified date [object]," and toLocaleString, which "converts a date to a string, using the current locale's conventions."

According to the documentation, "the getYear method returns either a two-digit or four-digit year: For years between and including 1900 and 1999, the value returned by getYear is the year minus 1900. For years less than 1900 or greater than 1999, the value returned by getYear is the four-digit year." This seems to contradict the Date object documentation's statement that dates prior to 1970 aren't allowed.

Testing by the InfoWorld Test Center revealed that both Navigator 3.01 and Navigator 4.01 in Netscape's Communicator will correctly store four-digit dates of years from 100 A.D. until 2999 A.D.

However, neither Netscape browser's version of toLocaleString will correctly display dates prior to 1900.

Though Netscape's documentation states that a call to getYear on years not in the 1900s will return a four-digit year, a call to getYear in Internet Explorer (IE) returns the year minus 1900. So a date in 2001 returns 101 from getYear. Although it acts as documented by Microsoft, this would make it difficult to write JavaScript involving date operations that is compatible across Microsoft and Netscape browsers.

Also, IE 3.02 doesn't work at all with dates before 1970. Microsoft has fixed most of the inconsistencies in the beta version of IE 4.0. Dates before 1970 worked as long as four-digit years were used.

Ultimately, the year-2000 JavaScript solution appears to be ECMAScript's getFullYear method. Neither Microsoft nor Netscape support it in the current release of their browsers, although both promise ECMAScript compliance.

Join the newsletter!

Error: Please check your email address.
Show Comments
[]