Re: real_time.clock is not monotonic

["Adam Beneschan" <adam@irvine.com>]

On Feb 21, 8:16 am, frederic.orman...@atosorigin.com wrote:
> I'm porting a GNAT application from Windows to Linux platform, and the
> application use two kinds of clock data :
> - Ada.Calendar.clock to obtain machine date and time, affect by NTP
> and daylight saving
> - Ada.real_Time.Clock, which use System.Os_Primitives.Monotonic_Clock
> to obtain a monotonic clock (for delays and time events generation)
>
> With Windows version of GNAT (3.15p), all is OK, monotonic clock use
> QueryPerformanceCounter() Win32 call to obtain a monotonic behaviour,
> but in Linux implementation of Gnat RunTime, Monotonic_Clock is a
> single rename of calendar.clock, which use gettimeofday() system
> call !!!!
>
> I'll alert Gnat community with this bad implementation, as
> gettimeofday() is affected by NTP and others date adjustements. in
> LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not
> compliant

Actually, I don't see in the LRM where it says "Ada.Real_Time.Clock
shall be monotonic", in such forceful language.  D.8(1) implies that
it's supposed to be.  However, D.8(36) says, "The implementation shall
document any aspects of the external environment that could interfere
with the clock behavior as defined in this clause", and a note in the
AARM says, "For example, the implementation is allowed to rely on the
time services of an underlying operating system, and this operating
system clock can implement time zones or allow the clock to be reset
by an operator. This dependence has to be documented".  Unless I'm
over-interpreting things, this last AARM note seems to imply that, in
some cases (such as the user manually changing the date or time),
Clock might *not* be monotonic.

Is my interpretation correct?  Does this mean that GNAT's
implementation is correct (if possibly undesirable to some users) as
long as it's documented?

                          -- Adam