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!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: Wed, 25 Aug 2004 09:24:48 +0200 Message-ID: References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de bto0YE+4g8K8xpnH2pXBmgCsH1D3EgDuexBwp7QrU4kdv3Jzg= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:2983 Date: 2004-08-25T09:24:48+02:00 List-Id: 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. > Moreover, Ada.Real_Time has no concept of dates, which is critical to using > a UTC time. Adding all of that to Ada.Real_Time would just make it a clone > of Calendar, which then would beg the question of why we need two different > time packages. For the same reason we have two of them now. The underlying clocks have different behavior. My point is that the nature of UTC clock is closer to one of real-time than to calendar. >> It is not warranted [guarenteed] that Clock /= Clock. > > Of course. How could it be? If two calls are sufficiently close together, > the clock may not have ticked in the interval. That's true even for > Ada.Real_Time.Clock; it only guarantees never to run backwards. It is a requirement when UTC is used for time stamping. Should Ada.Universal_Time be implemented as a separate package, one could fulfill it. For example, Clock could block until a tick which will change the result. It could be more than one, due to clock synchronization causing ignoring some ticks. Of course Clock should be bounded. Alternatively one could make clock reading artificially by adding "subtick" counter etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de