From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92471489ebbc99c6 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Y2K Issues Date: 1998/10/27 Message-ID: #1/1 X-Deja-AN: 405680019 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <713oes$dbn$1@nnrp1.dejanews.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-10-27T00:00:00+00:00 List-Id: dewarr@my-dejanews.com wrote: : In article <7125a8$e7u$1@nnrp1.dejanews.com>, : dennison@telepath.com wrote: : > In article <710nnc$jop@felix.seas.gwu.edu>, : > Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same problem. That surprises me, because the package Calendar we have shipped with our Ada 95 front end since the beginning has the following leap_year function (original comment included): function leap_year (the_year : year_number) return Boolean is -- This algorithm is good for 1901-2099 (LRM), but not beyond. begin return ((the_year rem 4) = 0); end leap_year; : > I understand it has been fixed in the current release, though. That's good. Maybe there is an interesting story here (or perhaps this whole thing is apocryphal?). : The remarkable thing about this (quite common) leap year bug is that it is : a great example of how a little knowledge can be a dangerous thing. Someone : who knows nothing about century corrections will get things right, someone : who knows how century corrections work will get things right, it is only : someone who knows about century corrections, but does not know how they : work who gets things wrong. Interestingly, we found a similar problem in the old Meridian front end, which was written in Pascal, which we licensed many moons ago for some Ada 83 products. The programmer went to some effort to correct for years that were a multiple of 100 and of 400, but ended up with it exactly wrong. Luckily, this was not in the Calendar package, but rather in the code which printed the date on the listing. The net effect is that listings using compilers based on the Meridian front end will print the wrong date from February 29th, 2000 to December 30th, 2000. If I remember correctly, they did manage to self-correct by the time 2001 comes along, so January 1st, 2001 will be correct. I don't know what will happen on December 31st, 2000. I suspect they will either print January 0, 2001, or December 32, 2000. : ...I have always assumed that one of the reasons : for the range of years in Ada is precisely that you don't have to worry : about century corrections :-) So much for trying to simplify the problem... : Robert Dewar -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company