Re: Inserting Calendar.Time in a database

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 25 Aug 2004 19:49:46 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net...
>> On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net...
>>> ...
>>>> I see a problem with it. UTC_Time_Offset is not constant, so there also
>>>> should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time
>>>> seems a better candidate for UTC. I would add it there.
>>>
>>> This is a gross misunderstanding of Ada's clock packages. Ada.Calendar
> is
>>> about time related to an external (standard) timebase, like UTC or CDT.
>>> Ada.Real_Time is about time related to an internal timebase. There is no
>>> defined relationship between Calendar and Real_Time, and that's
> intentional.
>>> Real_Time would typically be implemented with a hardware counter (such
> as
>>> QueryPerformanceCount on Windows).
>>
>> So should UTC clock. The major application area of UTC is time stamping in
>> distributed applications. The requirements on time stamps are very
>> different from of Ada.Calendar.Time.
> 
> Of course. "Time stamps" actually have nothing to do with time; the only
> requirement being that they be unique (and in some cases increasing).
> "Time" is usually used as a quick way to get them, but that is often a mistake
> (precision issues, time bases, etc.) It would be better to call them
> "generation stamps" or something like that. Certainly, you can use a UTC
> time to implement a "generation stamp", but it isn't such a thing, and it
> makes no sense to imply that it could be.

No. That would be just a stamp. A time stamp identifies the time of object
creation. One more typical example: you measure some signal and wish to
display it on-line as a wave form on the other side of the globe. Nether
measurement points are equidistant, nor something concrete could be said
about the communication channel.

> Moreover, we don't want to require
> a UTC time base in Ada, because embedded systems may not have access to an
> appropriate time base - and we certainly don't want to insist that every
> system be hooked up to the Internet!

It could be a child package. It could be a separate package described in
the Annex E.

> OTOH, UTC time really is about time (that is, years, months, days, hours,
> minutes, seconds), which makes it exactly appropriate for Ada.Calendar.

Ada.Real_Time is also about time. That you can view a clock reading as
year, month, etc tells nothing about time. It tells only about the time
base of the duration interval the clock return. The "system start" base is
as good as any other.

>> The source of clock synchronization is
>> less important. A pedant would say that the source is always external.
>> Quartz generators are not written in Ada, yet (:-)) It is no matter
>> whether
>> the clock is synchronized with a radio source or an internal quartz. Clock
>> behavior matters.
> 
> Yes, it matters a lot. Using locally determined UTC time as a generation
> stamp would be terrible if the systems are not synchronized to the same time
> base. That immediately takes it out the of realm of what the language can
> specify.

Does Ada.Calendar require that? It is quite legal set year 2090 on my
system. Why then Ada.Universal_Time should? We cannot influence the
precision of mapping the time base to UTC. So we should not specify it.

BTW, quite often the precision required for clock synchronization of nodes
is in order of magnitude lower than the required accuracy of clocks. For
example you need one second externally and one microsecond locally.

Essential is range, resolution and backward jumps.

>> For the same reason we have two of them now. The underlying clocks have
>> different behavior. My point is that the nature of UTC clock is closer to
>> one of real-time than to calendar.
> 
> You've obviously not had to sit thru hours of arguments with Tucker Taft on
> this topic!
> 
> One of the implementation models for Ada.Calendar (and one apparently used
> by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a
> monotomically increasing clock (usually UTC time). Localization is applied
> in Split. The reason for the design of the Ada.Calendar.Time_Zones is so
> that this implementation model can be applied. The important thing to
> realize here is that there is no *requirement* for the *actual* value of
> Ada.Calendar.Time to run backwards. There is no real difference in
> requirements between UTC time and Ada.Calendar.Time. Moreover, there is no
> requirement that Ada.Calendar.Time even default to local time. I think it
> would have been best if it in fact was required to be UTC time, but that
> would not have made sense in 1980 (popular OSes at that time provided no or
> very weak time zone support), and now we have a compatibility problem.

Do you want to strengthen Ada.Calendar requirements?

>>>> It is not warranted [guarenteed] that Clock /= Clock.
>>>
>>> Of course. How could it be? If two calls are sufficiently close
> together,
>>> the clock may not have ticked in the interval. That's true even for
>>> Ada.Real_Time.Clock; it only guarantees never to run backwards.
>>
>> It is a requirement when UTC is used for time stamping. Should
>> Ada.Universal_Time be implemented as a separate package, one could fulfill
>> it. For example, Clock could block until a tick which will change the
>> result. It could be more than one, due to clock synchronization causing
>> ignoring some ticks. Of course Clock should be bounded. Alternatively one
>> could make clock reading artificially by adding "subtick" counter etc.
> 
> That's clearly a requirement of your application which has nothing to do
> with the definition of Time. Your "generation stamp" package should be
> designed to guarantee this property if it is needed; it's a rare enough
> requirement that there isn't any reason to build it into the language.

I do not think so. Application areas are: time stamping, time
synchronization in distributed systems, data logging, remote control,
remote data acquisition, communication protocols requiring time.

> Also note that your original complaint is bogus:
> 
>> I see a problem with it. UTC_Time_Offset is not constant, so there also
>> should be an atomic way to get exact UTC.
> 
> There is, you're just doing the operations in the wrong order:
> 
>     declare
>           A_Time : Ada.Calendar.Time := Ada.Calendar.Clock;
>           UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset :=
>                 Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time);
>     begin
>           -- Do Split or other operations using UTC_Adjustment.
>     end;
> 
> 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? 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?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de