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!peer01.cox.net!cox.net!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Inserting Calendar.Time in a database Date: 26 Aug 2004 06:22:38 +0100 Organization: Pushface Sender: simon@smaug.pushface.org Message-ID: References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> NNTP-Posting-Host: pogner.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1093498096 20429 62.49.19.209 (26 Aug 2004 05:28:16 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 26 Aug 2004 05:28:16 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Xref: g2news1.google.com comp.lang.ada:3009 Date: 2004-08-26T06:22:38+01:00 List-Id: "Dmitry A. Kazakov" writes: > On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" 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. 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. The major application area of Ada.Real_Time is in running real-time systems which is jargon for systems that must meet their deadlines. There is no requirement at all for UTC or anything like that from that part of the embedded market. -- Simon Wright 100% Ada, no bugs.