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,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Y2.1K (was: Ada vs C++ vs Java) Date: 1999/02/05 Message-ID: #1/1 X-Deja-AN: 441082127 Sender: bobduff@world.std.com (Robert A Duff) References: <369C1F31.AE5AF7EF@concentric.net> <369CBAED.20BE91CA@pwfl.com> <369CF2EF.AC875B2A@gecm.com> <78i6m1$505$3@plug.news.pipex.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-02-05T00:00:00+00:00 List-Id: "Nick Roberts" writes: > As a matter of interest, if I were to declare Ada.Calendar.Year_Number as > having the range 0001..9999 (in line with the standard SQL definition of a > year), instead of 1901..2099 as required in the RM, would this be likely to > cause my compiler to fail the ACVC? ... Interesting question. I changed one of our (Averstar's) Ada implementations (for the ADI SHARC target -- a cross compiler running on Windows NT) in the way you suggested. I ran the ACVC and got 100% passing. So the answer to your question appears to be "No". Of course, this thing is no longer an Ada implementation. I wouldn't want to sign the Delaration of Conformance after having so deliberately disobeyed the standard! And of course, there could be a new ACVC test at any time, that checks that Year'Last = 2099. By making this change, I broke the leap-year calculation, which depends on the existing range of Year. But of course the ACVC couldn't notice that, and I didn't bother to fix it, since I was doing a throw-away experiment just for fun. By the way, I think ACVC is now called ACATS. But I have trouble breaking the habit -- just like lots of people say "rep specs" instead of "rep clauses", and I sometimes say "protected record" instead of "protected object". And "Intermetrics" instead of "Averstar". ;-) >... Would it actually be a problem to anyone > (porting their existing code to my compiler)? It seems fairly unlikely to cause trouble. But it *could*. It also seems fairly unlikely to cause any good -- 2099 is a long ways off. I hope the state of the art in language design has advanced a bit by then! >... Obviously it would potentially > be a problem to anyone requiring portability: but not if they wrote their > code carefully. Would anyone object? I object. Your suggestion makes sense to me as a language change. Maybe the next version of Ada will make the change. But it seems naughty to just go off and do such a thing on your own. You could submit it to the ARG if you like. > I realise I would have to ensure the Ada.Calendar.Time type was able to > encompass these years, and that I would have to ensure leap years were > calculated correctly. I would use an assumed Gregorian calendar for all > dates (as specified for SQL). That makes sense. (I've always been confused by people who object to increasing the range into the past, because the people alive back then used a different calendar. I mean, doesn't it make perfect sense for me to talk about something that happened in the year 100, even though the people alive then called it something else?) - Bob -- Change robert to bob to get my real email address. Sorry.