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 22:04:51 +0200 Organization: At home Message-ID: <2p6u06Fh8m2oU1@uni-berlin.de> References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> <19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.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 aqfbB621qyfELYn7VcrlfAosSm6fIMgDsEobzPYsLqA7hvp34= User-Agent: KNode/0.7.7 Xref: g2news1.google.com comp.lang.ada:3046 Date: 2004-08-26T22:04:51+02:00 List-Id: Randy Brukardt wrote: > 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, Agree > 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. But normally it is all that required, no more! Why not to put it the standard? If that cannot be supported on all platforms, then it could be a separate optional package. > In any case, the sorts of requirements that you have are simply not > supportable within the standard. You mean X1 := Clock; X2 := Clock; then X1 < X2? If the *optional* package would be required to have Time at least 64-bit, would then X1 < X2 be such a big burden? > (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. Absolutely. Time synchronization should be left outside. The standard should only require a reasonable range -200..+200 years from now, fine resolution 1..100 nano, no backward jumps, unique readings for same task. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de