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/19 Message-ID: #1/1 X-Deja-AN: 402894663 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <362B53A3.64E266AB@res.raytheon.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-10-19T00:00:00+00:00 List-Id: John J Cupak Jr (John_J_Cupak@res.raytheon.com) wrote: : ... : I hope this question has not been posted yet. If so, I missed it even : though I looked in Deja News. : What is the effect of the Y2K problem on date calculations in Ada (both : 83 and 95). : If this is a compiler vendor issue, what compilers have "certified" : their date calculations Y2K correct? It is certainly compiler-specific, but from a language point of view, because Time is a private type, it less likely that there will be a year 2000 problem. If there is one, it is more often in the reliance on some non-Y2K-compliant system call. E.g., in the IBM MVS world, the "old" MVS system call only gave back a 2-digit year. The typical MVS Ada compiler (of which there aren't many!) probably just added 1900 to that to produce the year. Such a compiler would have to be fixed to use the "new" MVS system call which returns more digits. Chances are most Unix-hosted Ada compilers have a Y2038 problem (when the Unix 32-bit time goes negative). : I also note that the Ada 95 LRM (RM96;6.0) Ada.Calendar package defines : the Year_Number as range 1901..2099. What happens in 2099? The world : ends? There is admittedly a "Y2.1K" problem in Ada, but it is pretty benign, because it is so straightforward to extend the definition of Calendar.Year_Number to be 1901..2999 (or more). No code outside of Calendar would have to change. I presume the reason for the original range was to minimize the amount of code inside Calendar which needed to be devoted to leap year calculations. 1901..2099 is the longest consecutive interval which includes today for which the simple rule that every 4 years is a leap year applies. Neither 1900 nor 2100 are leap years, due to the second order correction in the leap year formula. We saw no reason to change the Year_Number range during the Ada 9X revision. We figured we wanted to leave something to the Ada 205X revision ;-). : Thanks, : John Cupak : Raytheon -Tucker Taft stt@inmet.com