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: Wed, 25 Aug 2004 19:48:50 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> Subject: Re: Inserting Calendar.Time in a database Date: Wed, 25 Aug 2004 19:49:46 -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-5KQlxbxsSbhp7yjZ3LrPoyqoLQMT7BP7LCMUbm0yLLEKEv+0+ODrMtgzvg3yAcoxQo1R/d+s46fTrak!r6YjoSMTc9hlqNawZjSwwIMCSWy5ttV1xXZBafQuhbgiPahp9qgPzA8URd8XrOJnKlchoD67InDI 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:3002 Date: 2004-08-25T19:49:46-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net... > 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. Of course. "Time stamps" actually have nothing to do with time; the only requirement being that they be unique (and in some cases increasing). "Time" is usually used as a quick way to get them, but that is often a mistake (precision issues, time bases, etc.) It would be better to call them "generation stamps" or something like that. Certainly, you can use a UTC time to implement a "generation stamp", but it isn't such a thing, and it makes no sense to imply that it could be. Moreover, we don't want to require a UTC time base in Ada, because embedded systems may not have access to an appropriate time base - and we certainly don't want to insist that every system be hooked up to the Internet! OTOH, UTC time really is about time (that is, years, months, days, hours, minutes, seconds), which makes it exactly appropriate for Ada.Calendar. > 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. Yes, it matters a lot. Using locally determined UTC time as a generation stamp would be terrible if the systems are not synchronized to the same time base. That immediately takes it out the of realm of what the language can specify. > > 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. You've obviously not had to sit thru hours of arguments with Tucker Taft on this topic! One of the implementation models for Ada.Calendar (and one apparently used by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a monotomically increasing clock (usually UTC time). Localization is applied in Split. The reason for the design of the Ada.Calendar.Time_Zones is so that this implementation model can be applied. The important thing to realize here is that there is no *requirement* for the *actual* value of Ada.Calendar.Time to run backwards. There is no real difference in requirements between UTC time and Ada.Calendar.Time. Moreover, there is no requirement that Ada.Calendar.Time even default to local time. I think it would have been best if it in fact was required to be UTC time, but that would not have made sense in 1980 (popular OSes at that time provided no or very weak time zone support), and now we have a compatibility problem. > >> 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. That's clearly a requirement of your application which has nothing to do with the definition of Time. Your "generation stamp" package should be designed to guarantee this property if it is needed; it's a rare enough requirement that there isn't any reason to build it into the language. Also note that your original complaint is bogus: > I see a problem with it. UTC_Time_Offset is not constant, so there also should be > an atomic way to get exact UTC. There is, you're just doing the operations in the wrong order: declare A_Time : Ada.Calendar.Time := Ada.Calendar.Clock; UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset := Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time); begin -- Do Split or other operations using UTC_Adjustment. end; 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. Also note that using Tucker's model, you can't apply the adjustment to the time value, rather it only is used in calls to Split or other formatting routines. For use a generation stamp, you'll have to reformat this into something that you can pass around anyway, so that's not a real problem. And it's no problem to encapsulate all of this into a generation stamp package that does the needed conversions under the covers -- the best plan in any case (as you'll need control over the format of the stamps for streaming or whatever -- you don't want this breaking if you move to a different compiler). Randy.