At 09:42 05-01-00 , Peter Benoit wrote:
>What I mean was that they probably realized somewhere 
>along the way that Netscape goofed up with the getYear() 
>method, 

I understand what you are saying. But Netscape didn't ~goof~ when they
choose to present the value it units that were familiar with many who would
be using it. Nor would they have ~goofed~ had they chosen to provide the
result in roman numerals. As long as the value provided is correct, they
did not ~goof~.

You can argue if you wish that returning an integer year would be less
confusing to non-programmers, but would need to concede there would then be
possible confusion by those already familiar with the convention of a 1900
offset. [Yes, MS-DOS does use a 1980 offset, but likely only a relatively
small number of programmers have worked in that environment. Further I
doubt that any extant body of library routines might be an issue.]

Since routines and algorithms exist for the familiar year representation,
as well as the broad body of experience, there are quite valid engineering
arguments for the definition Netscape used. as well as arguments for using
an integral year.

No matter how an API returns (and receives) values, some will favor that
approach, and others need to adapt. Such is the nature of the beast. If the
unit is temperature, some will prefer F, some C, and some K. For time,
we've the whole local time or GMT dilemma. For angles, whether radians or
degrees. [API=application programming interface, GMT=UT=universal time]

Similarly, for dates. Arguably use of roman numerals would require the most
extra effort by most people (and likely engender some debate over optimal
normalization of results, since some numbers may be represented in several
way), but we've a key distinction between engineering efficiency and valid
results.

>and changed IE to accept getYear() as a 4 length year.  

Accept? Isn't this an issue of what they return (provide) rather than what
they accept? Not only so they report the year 2000 as 3900, but they have
the audacity to claim that such a product is Y2K compliant. [0] 

They are giving the wrong result. that's all there is to it.

>No proof of this of course, it's just supposition.

Yep. On this acknowledgement we do agree.

Safe computing,  /Harold
=======================
[0] To keep things in context, this is the same Microsoft that released NT
4 Service Pack 5 as Y2K compliant, with the warning that one must not
install certain components on the last day of February of any leap year,
the consequence will be the destruction of a key security data base!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harold A. Driscoll                 mailto:Harold(at)Driscoll.Chi.IL.US
#include <std/disclaimer>                 http://Driscoll.Chi.IL.US

HWG: hwg-languages mailing list archives, maintained by Webmasters @ IWA