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,FREEMAIL_FROM, 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: Charles Hixson Subject: Re: Calling C time function from ADA-95 Date: 1998/06/09 Message-ID: <357D5083.45CB71F1@earthling.net>#1/1 X-Deja-AN: 361050369 Content-Transfer-Encoding: 7bit References: <3579da75.13533758@enews.newsguy.com> <357C141E.D868661F@earthling.net> <6lhnan$1vi$1@goanna.cs.rmit.edu.au> <357D166E.685D7A09@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: http://extra.newsguy.com Newsgroups: comp.lang.ada Date: 1998-06-09T00:00:00+00:00 List-Id: That may be so. But my interest in small pieces of time declines as their distance from me increases. Thus, I doubt that I will ever be interested in which hour Cleopatra met Marc Antony. The season might be of interest, or the year, but hardly more than that. When issuing cards to people, I want to represent their birthdate, even if it happened before 1900 (a declining number, I admit). I'm not interested in the second that they were born, or even the minute (or, for that matter, the hour..but I think that the hour should be kept). . I think that times should be kept on a kind of sliding scale. Say seconds for the current decade, minutes for the current century, hours for the current 100 centuries. Days for the current 10,000 centuries. Etc. That should be sufficient overkill for ANYONE that would be satisfied by the current date structure anyway. And for the for any time within the last/next day or two milliseconds could be specified. Basically this is intended as a computationally cheaper (right? wrong?) substitute for the log of the number of time units away from NOW Astrophysicists and Quantum Mechanics, of course, would still need their own special date structures, but they couldn't use the standard scale anyway. Markus Kuhn wrote: > > 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: -- Charles Hixson charleshixson@earthling.net (510) 464-7733 or chixso@mtc.dst.ca.us