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,814bd9dd1692da42 X-Google-Attributes: gid103376,public From: Markus Kuhn Subject: Re: Calling C time function from ADA-95 Date: 1998/06/09 Message-ID: <357D166E.685D7A09@cl.cam.ac.uk>#1/1 X-Deja-AN: 360980801 Content-Transfer-Encoding: 7bit References: <3579da75.13533758@enews.newsguy.com> <357C141E.D868661F@earthling.net> <6lhnan$1vi$1@goanna.cs.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Cambridge University, Computer Laboratory Newsgroups: comp.lang.ada Date: 1998-06-09T00:00:00+00:00 List-Id: Dale Stanbrough wrote: > > Charles Hixson writes: > > "Well, since you asked, the year type of Calendar has a **much** too > restricted range. Saving space by restricting the size of the year that > way reminds me of all of the programs that stored only two digits for > their year in the '60s, and now their descendants are delighting > everyone." > > I always thought the range was chosen to allow for fast leap year > calculations (year mod 4, excluding the more expensive mod 100/mod 400) > rather than to save space. Does anyone have any better knowledge? Many existing systems (most likely your Unix workstation as well!) do not handle leap years correctly outside the 1901..2099 range. The Ada95 standard just documents a restriction that is not imposed by the Ada standard, but by many commonly used operating systems. It is foolish to access the C API directly for this reason because (although this is rarely documented), it also has only a valid year range until 2099: For instance POSIX.1 (ISO/IEC 9945-1:1996) defines its time scale as follows 2.2.2.113 seconds since the Epoch: A value to be interpreted as the number of seconds between a specified time and the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1990 (tm_year) is related to a time represented as seconds since the Epoch, according to the expression below. If the year < 1970 or the value is negative, the relationship is undefined. If the year >= 1970 and the value is nonnegative, the value is related to a Coordinated Universal time name according to the expression: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86_400 + (tm_year-70)*31_536_000 + ((tm_year-69)/4*86_400 There will be a 86400 s log gap between 2100-02-28 24:00:00Z and 2100-03-01 00:00:00Z (same for the years 2200, 2300, 2500, ...), because the leap year rule used in the above formula is only valid in the year interval 1901..2099. This is not of concern when the seconds since the Epoch are counted in 32-bit signed integer variables, which will overflow on 2038-01-19 03:14:08Z, but on 64-bit machines, this should be fixed, since the Y2K problem has tought us that it is conceivable that software will be in use for centuries and it is ulikely that mankind will agree on a new calendar scheme any time soon given the enourmous problems that even a century roll-over causes in our IT infrastructure. The correct formula (I think :) would be: tm_sec + tm_min * 60 + tm_hour * 3600 + tm_yday * 86_400 + (tm_year-70) * 31_536_000 + ((tm_year-69)/4 - (tm_year-1)/100 + (tm_year+299)/400) * 86_400 If this were widely implemented and time_t were a 64-bit signed integer on POSIX systems, then the year range could be extended to the year 9999. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: