From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e686c2c95beefb1c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Inserting Calendar.Time in a database Date: Thu, 26 Aug 2004 12:58:21 +0200 Organization: At home Message-ID: <2p5tveFh9md6U1@uni-berlin.de> References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> <19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.net> <412db53f$1_1@baen1673807.greenlnk.net> Reply-To: mailbox@dmitry-kazakov.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de nWXGSRJNw+rEmRd4Ru4SPQTjKeEwEKEoM16mSGA2UjJRaaQgU= User-Agent: KNode/0.7.7 Xref: g2news1.google.com comp.lang.ada:3019 Date: 2004-08-26T12:58:21+02:00 List-Id: 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