Re: Any leap year issues caused by Ada yesterday?

[Simon Wright <simon@pushface.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 06 Mar 2012 17:59:04 +0000, Simon Wright wrote:
>
>> The timebase ran off the same crystal as the decrementer, so all were
>> internally sync'd. Internally, our synchronised time was
>> (Ada.Calendar.Clock (at last clock interrupt, of course) + high-res time
>> since last clock interrupt).
>
> You could improve that a bit by putting Ada.Calendar.Clock into a loop.
> When it returns a different value, you exit the loop and take that value
> for the time base.

Ada.Calendar.Clock was basically the POSIX gettimeofday() (?) from
VxWorks; which was (epoch + ticks/clockrate). So it was updated at clock
interrupt.

> If the quartz is same you need not to synchronize it anymore. Since the
> multiplier is known you simply add the RTC minus its value at the base
> multiplied by the factor and converted to Duration (or Time_Span) to the
> base and use that instead of the original Ada's Clock.

Didn't want to mess with the RTS use of Ada.Calendar.Time for delays. No
point in using Ada.Real_Time.Time because (then) it was the same as
Ada.Calendar.Time. So we had AC.Time (for internal use only),
<Project>.Calendar.Time for both internal & external use (but not, of
course, for delays).

> Did you check the kernel settings? It has a variable that sets the time
> source to the RTC. This might work on your PPC's BSP. The effect is that
> the system clock is changed each time when queried rather than upon timer
> interrupts.

Don't remember that one.