Re: Any leap year issues caused by Ada yesterday?

[Simon Wright <simon@pushface.org>]

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

> On Mon, 05 Mar 2012 18:30:46 +0000, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> BTW, I would not wonder to see Real_Time.Time and Calendar.Time same
>>> or correlated.
>> 
>> We were surprised and disappointed to find that earlier releases of GNAT
>> did have them the same. What happens to your precise timing if you get
>> an NTP update in the middle of it?
>
> Nothing, because I would expect the NTP client to leave alone the clock
> readings and the arithmetic of. It should rather adjust Split and Time_Of.

Some people would arrange time sync such that if:

a) you read the clock
b) time sync sets the clock back 1 second
c) after 1 second you read the clock again

that the time read at a) and c) would be the same. 

> In our setups we are using a different schema anyway. Instead of
> adjusting clocks we do the time stamps when sending them from host to
> host.

Because of the GNAT bug we couldn't use Ada.Real_Time. So we left
Ada.Calendar untouched and made our own <project>.Calendar with offsets,
as you say. Fun with I/O of time,

>> OK, this is slightly GNAT-related, since (at that time, anyway) "delay
>> 0.5" translated under the hood into "delay until now + 0.5" on VxWorks,
>
> Yes, but NTP should not mingle in that. [I don't know how the VxWorks NTP
> client works.]

I don't understand? What else would it do but change the value of
Ada.Calendar.Clock?

>> so you were always related to the actual clock.
>
> VxWorks clock on i7 is a garbage. It is driven by the timer interrupts,
> i.e. to get 1ms resolution you need 1000 interrupts per second.
>
> We keep on asking Wind River to fix the mess, but without much success so
> far. GNAT simply uses that clock. So delay 0.001 may mean absolutely
> anything under VxWorks. To fix that one should rewrite the time driver.

We were quite happy with 1 ms ticks. So delay 0.001 meant "delay at
least 1 and no more than 2 ms" (like always).

>> AdaCore accepted the bug report (after we pointed out the "shall" in
>> ARM95 D.8(32)).
>
> Well, I would not blame AdaCore for that, it is Wind River's fault,
> IMO.

This was *Ada* running on VxWorks; so it needed fixing. We didn't care
who fixed it (well, as far as we were concerned, who didn't fix it,
actually).

It should have been easy enough on VxWorks: taskDelay(period + 1); (but
there may be all sorts of complicated reasons why that wouldn't be
enough).