Re: Calling C time function from ADA-95

[Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>]

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: <http://www.cl.cam.ac.uk/~mgk25/>