Re: ada calendar

["Randy Brukardt" <randy@rrsoftware.com>]

"Thomas Wolf" <t_wolf@angelfire.com> wrote in message
news:MPG.1a412f88b61dac9c989681@news.ip-plus.ch...
> rieachus@comcast.net wrote:
> > The latest version of the proposed additions for Ada 0Y can be found at:
> > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00351.TXT?rev=1.2>
>
> I see that this proposal includes some functionality for dealing with
> leap seconds. It proposes (among other things)
...
> How is this supposed to work if Left or both Left and Right are in
> the future? You cannot predict when the next leap second will be
> inserted -- it depends on the irregularities of Earth's rotation,
> and IERS inserts a leap second whenever necessary (well, at the end
> of June or December) to keep the difference between UT1 und UTC <
> 0.9 sec.
>
> Also implementing this for past dates needs a look-up table.

No, you failed to read the Implementation Advice. The intent is that this is
mapped to whatever functionality is provided by the underlying timebase. In
particular, if the timebase doesn't provide leap second information, all of
these routines should return zero for the number of leap seconds. (And, by
definition, that should be true for times in the future.)

The only reason for these functions is so that using a timebase that does
provide leap seconds (and they are getting more common) won't screw up
programs.

Note that I personally think these leap second functions are a mistake.
There are sometimes 86401.0 seconds in a day, and Ada should simply be
honest and say that. (Indeed, doing so makes the other functions in this AI
more critical, because the assumptions used in typical code are wrong.)

In any case, the ARG is far from a resolution on this proposal. (We didn't
discuss it in San Diego, the only Amendment AI that we didn't look at.)

                 Randy Brukardt
                 ARG Editor (and author of AI-351).