Re: Leap Seconds

[Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann)]

On 29-May-01 Marin David Condic wrote:
> Well, its actually a "requirement" that is spelled out in a standards
> document that is not (yet) accepted by the FCC (AFIK). WRT
> "event_start_time", the standard says: "A 32-bit unsigned integer quantity
> representing the start time of this alert event as the number of seconds
> since 00 hours UTC, January 6th, 1980 with the count of interleaving leap
> seconds included."
> 
> The situation is this: The source *may* be able to produce that time base &
> interleaving leap seconds. It would require a leap-second table that is
> periodically updated as new leap seconds happen - with the possibility that
> there is some delay between the leap-second and the table update. (In this
> app it isn't critical, but it might one day be critical in some other
> area...) The local time base is different and won't have access to any sort
> of leap-second update table. (Again, in this situation being off by a few
> seconds is not a big deal - but it might be in other parts of the
> application.) I can correct with a constant plus a "tuning" value sent from
> the source - if available - that represents leap seconds & hence we can be
> on the same time base. Hence a solution does exist.

I fail to see the problem here. "event_start_time" allows to operate a clock
which just counts _every_ second and to compute correct time differences
without using any tables or corrections from outside. Its only problems are
conversions to and from human readable form -- but if noone is there to install
new leap second tables, then noone will request such conversions there. All time
stamps used in communication with the outside world would be "event_start_time"
values. 

One pitfall remains: Someone asking for something to be done every day
precisely at noon. Then you will have to convince her or him that a
precisely _regular_ interval would be much better... :-))

Ada support is found in Ada.Real_Time. If I interpret the ARM correctly,
Real_Time counts each and every second and so it has to count added leap
seconds and it may not count omitted leap seconds. So it just has an offset to
the event_start_time and perhaps some (solvable) computational problems as
real_time spans have a small guaranteed range (1 hour) compared to real_time
stamps (50 years from program start-up).

Wilhelm