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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 26 Aug 2004 13:54:48 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> <19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.net> Subject: Re: Inserting Calendar.Time in a database Date: Thu, 26 Aug 2004 13:55:43 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-U4n2oZwbm/wCxfp/6Ysnw4SvsQ8gzWo4RcNRk6bjYPjI0ZG0sjKeAHyxBrL+x528gWFVVcXgyNM7IEW!eA198XiH/KkNY+NX0yWQj2DY/WasbTo7xfiOM54vFFAzae1/a4fx0tzIHbGnOLrSKIGXRvNTU6OI X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.13 Xref: g2news1.google.com comp.lang.ada:3042 Date: 2004-08-26T13:55:43-05:00 List-Id: "Dmitry A. Kazakov" 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.