Re: Inserting Calendar.Time in a database

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.net...
...
> > The point is that you must never save values of UTC_Adjustment, but
rather
> > recalculate them each time. Hopefully the implementation of
> > Ada.Calendar.Time_Zones doesn't make this too expensive.
>
> So UTC_Time_Offset should remember the local zone time adjusting history
> and also foresee all future adjustments? How efficient it would be?

It's just a system call of some sort, its certainly no worse than calling
Clock itself and probably is much better.

> Say, there are 32 1kHz channels, for each value I need a time stamp. A
real-life
> application should convert Ada...Clock to FILETIME. It would using Split +
> the formula for leap years, seconds etc, all that in an interrupt handler?

The overhead of calling Clock is such that it would not make sense to do
this on many existing implementations, even if you use Ada.Real_Time. It
certainly would make no sense on any system built on top of Windows or Unix
or Linux. The adjustment to the local time isn't a big enough portion of
that overhead to matter much.

I would expect that it might be possible on some real-time kernels. For
those, it's clear that Ada.Calendar.Time should be UTC time, and a child
package provided to get the Local_Time_Offset if that is needed. (That
really ought to be required behavior of Calendar, but it's simply too
incompatible - and in the worst way, at run time - to do.)

An alternative (especially in the inprecise requirements that you suggested
in your message) is to figure the time base of Ada.Real_Time, then using
Real_Time for most operations. Indeed, this is exactly how Calendar is
implemented on Janus/Ada and on GNAT for Windows: the system time functions
are used to get the time base, and QueryPerformanceCounter is used to get
high precision time information within that time base. (Of course, the fact
that QueryPerformanceCounter leaps forward many seconds on some hardware is
a problem.) We rebase every 5 minutes to avoid drift problems from using two
separate clocks; I believe GNAT is similar.

In any case, the sorts of requirements that you have are simply not
supportable within the standard. (Or implementations, for that matter.) No
Ada vendor is going to guarantee anything about the accuracy of the time
base (because it's completely out of their control), which is a necessary
parameter in any sort of distributed system. Either it doesn't matter much
(as in HTTP), or you are going to have to take steps to insure that it is
accurate enough, and that requires going beyond anything that the standard
could possibly give you.

                       Randy.