Re: Inserting Calendar.Time in a database

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

Martin Dowie wrote:

> Dmitry A. Kazakov wrote:
>> 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.
> 
> Er, sorry, that's just not how the word "timestamp" is used either in
> English or in engineering (at least here in the UK) - it does not need to
> be tied to UTC or local time or anything other than 'time from
> reset' (usually). 

There is no time from reset, because there was no reset. Consider publishers
broadcasting data.

Well, after all any time scale has its 0, call it reset time, if you want.
So what is the point? That the time bias shall be indeterminable?

> So long
> as the period between 'ticks' is known then you have all the information
> you need.

Only theoretically, practically the errors will accumulate making the whole
system unusable. Note also that some ticks might get lost. Consider a data
logger working remotely...

> It may be that you need to synch several boards but all you need to do is
> find
> the relative differences between the different start points (i.e. where
> each board thought '0' was).

More than that. You have to do it periodically. I.e. you have to synchronize
time, no more no less. Now consider that your boards communicate in a
many-to-many way. Data have different periods, are event controlled; there
are publisher/subscriber issues etc. What you propose is in fact to
synchronize time for *each* peer-to-peer connection. Apart from being
unrealistic and extremely complex, time/traffic consuming, consider a
possiblity that there already exist radio clock devices doing that much
better. It is no seller.

No real application will do that. It will get UTC from OS in some
OS-specific way, as it happens now.

>> 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.
> 
> ...and that's exactly why you don't need UTC! :-)

So you actually disagree with Randy! (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de