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,335675a1cb969fdb X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Calendar.Time_Zones Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net> <3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net> Date: Thu, 7 Aug 2008 10:27:35 +0200 Message-ID: <61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net> NNTP-Posting-Date: 07 Aug 2008 10:27:35 CEST NNTP-Posting-Host: 6752ce2c.newsspool3.arcor-online.net X-Trace: DXC=c\eFlK9?IWh_0Po7BmQ3]lMcF=Q^Z^V3h4Fo<]lROoRa4nDHegD_]Re5m;Ul8AADNl[6LHn;2LCVn7enW;^6ZC`dIXm65S@:3>oLeU>YKdB7]o X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1493 Date: 2008-08-07T10:27:35+02:00 List-Id: On Wed, 6 Aug 2008 21:52:53 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net... >> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net... >>>> Does anybody know the meaning of the result returned by UTC_Time_Offset? >>> >>> It's as the RM says. >> >> But how to translate what it says into concrete numbers: >> >> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =? >> >> OK, I am posting that to Ada comments as you suggested. > > I don't think the RM answers your question, which technically means that it > is unspecified. Which perplexes me much. How could it happen that an Ada library function has undefined behavior. > It is reasonable to ask if it *ought* to be unspecified, > which is why I asked you to ask the ARG. Yes, I did. >>> It's pretty obvious, though, that there is no way to do this correctly >>> unless the time type is based on UTC (time-zone-less) time. And because >>> of >>> compatibility concerns, the only way to do that is to completely junk >>> Ada.Calendar and start over, duplicating essentially everything. You're >>> probably right that we should have done that, but it would always be a >>> tough >>> sell (lots of people would say that Ada.Calendar is "good enough") -- >>> which >>> is why you need to ask this question directly to the ARG. (And get as >>> many >>> people as possible to support it, too.) I alone could never produce >>> critical >>> mass on this topic. >> >> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic, >> Ada.Calendar.Formatting are all new packages. All of them have an >> inconsistent semantics, because Time_Of is necessarily inconsistent [*]. >> Zone offset is simply not a function of the local time. It is of the UTC >> time. > > You'd have to completely duplicate the contents of Ada.Calendar using a new, > very similar time type that is based on UTC. Hmm, is Ada.Calendar big? Anyway one didn't hesitate to duplicate most of it in Ada.Calendar.Arithmetic. But all that stuff like Time_Of etc is not really needed with UTC_Time. The package should provide Clock, +, -, <, <=, >, >=: package Ada.UTC_Time is type UTC_Time is private; function Clock return UTC_Time; function "+" (Left : UTC_Time; Right : Duration) return UTC_Time; function "+" (Left : Duration; Right : UTC_Time) return UTC_Time; function "-" (Left : UTC_Time; Right : Duration) return UTC_Time; function "-" (Left : UTC_Time; UTC_Time : Time) return Duration; function "<" (Left, Right : UTC_Time) return Boolean; function "<="(Left, Right : UTC_Time) return Boolean; function ">" (Left, Right : UTC_Time) return Boolean; function ">="(Left, Right : UTC_Time) return Boolean; end Ada.UTC_Time; That's it. Then: package Ada.UTC_Time.Time_Zones is type Time_Offset is range -28*60 .. 28*60; -- This is well-defined function UTC_Time_Offset (Date : UTC_Time := Clock) return Time_Offset; function To_Calendar_Time (Time : UTC_Time; Time_Zone) return Time; function To_Calendar_Time (Time : UTC_Time; Time_Zone; Time_Offset) return Time; -- Time Zone is always required for the backward conversion function To_UTC_Time (Time : Time; Time_Zone; Time_Offset) return Time; end Ada.UTC_Time.Time_Zones; I would also like to see conversions between Ada.Real_Time.Time and UTC_Time. > The real question is whether the hole is important enough to try to fix > (given that the fix is going require adding a lot more mechanism). That's a > question I can't answer. Our problem is that we need to exchange time-stamped data with the outside world. So we have to convert UTC forth and back to Ada.Real_Time.Time. It is to expect that the system might become out of service for when the clock is adjusted. Considering similar cases, like air flight traffic control systems dealing with GPS clock etc, I wonder how they would handle that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de