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: Gautier.DeMontmollin@maths.unine.ch Subject: Re: Y2K Issues Date: 1998/10/28 Message-ID: #1/1 X-Deja-AN: 405964387 References: <362B53A3.64E266AB@res.raytheon.com> <36365724.EF1CC215@maths.unine.ch> <7166p4$poe$1@nnrp1.dejanews.com> Organization: University of Neuchatel, Switzerland Newsgroups: comp.lang.ada Date: 1998-10-28T00:00:00+00:00 List-Id: > Why should this be a shock? The standard library packages are provided to > cover standard needs, not all possible needs! If you need a calendar package > that covers a longer period, then build, buy or otherwise acquire one, just > as you would do for lots of other specialized functionality. "Standard" depends on what usage is expected from Ada language... Since it is a powerful and comfortable tool in many other domains than real-time systems (I think in present context to statistics or nature sciences), the 1901..2099 range seems to me _a bit_ narrow. Apparently - as you write - it's not a problem of sparing some bits or adding lots of leap years code. Of course it's very easy to write a sort of Long_Calendar from GNAT library sources but I already see people using the wrong Calendar etc... But maybe there are solid reasons for that range, like the ability of doing 8-bit arithmetics (199<256) with the years... -- Gautier