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.0 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,59c3b3f9911c9191 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.177.12 with SMTP id bg12mr1468134qab.0.1343316339113; Thu, 26 Jul 2012 08:25:39 -0700 (PDT) Received: by 10.66.85.231 with SMTP id k7mr1816402paz.38.1343316339036; Thu, 26 Jul 2012 08:25:39 -0700 (PDT) Path: a15ni113198934qag.0!nntp.google.com!q21no5764571qas.0!news-out.google.com!b9ni65098454pbl.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newspump.sol.net!xlned.com!feeder5.xlned.com!feed.xsnews.nl!border-1.ams.xsnews.nl!newsfeed.straub-nv.de!news.swapon.de!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada.Calendar and NTP (and Unix Epoch) Date: Tue, 24 Jul 2012 22:17:44 +0200 Organization: cbb software GmbH Message-ID: References: <500dc548$0$2936$f40e02c5@shockwave.dk.telia.net> <18893cca-baa2-4930-bfb4-4c4f7eb7e983@googlegroups.com> <60c9c92b-280b-4178-a410-2bc8756c6b5e@googlegroups.com> <5513b36d-560f-42ee-b6b6-bdb456097780@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-07-24T22:17:44+02:00 List-Id: On Tue, 24 Jul 2012 12:07:52 -0700 (PDT), Adam Beneschan wrote: > On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote: >> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote: >> >> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. >> > Or, better, if the NTP time is always UTC, then you should probably use >> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight >> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone => >> > Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct me if >> > I'm supposed to negate the value.) >> >> There is no simple way of converting Ada.Calendar.Time to UTC. At least >> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or >> sort of. > > The problem here, I think, is that the concept of "converting > Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat > vague. I'm not trying to explain how to work with UTC time in general; > I'm trying to solve a specific problem. > > The specific problem (as I understood it) was this: You have an integer > value that represents a specific *point* *in* *time* T1 by specifying the > number of seconds that have elapsed since midnight on New Years Day in > Greenwich. T1 [GMT] > You have another value that was returned by Ada.Calendar.Clock at some > other point in time T2. T2 [nobody knows what] > My contention is that you can create an Ada.Calendar.Time value to > represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable > Time_Offset, The problem is the Time_Offset, where do you get it? You need GMT_Time_Offset, which firstly is not defined, and secondly if it were there, it would be no more constant than the UTC_Time_Offset is. Once you get T1 and T2 to the same time basis of more or less monotonic time, e.g. GMT, UTC, whatever, but *not* a political time, there will be no further problems. > Furthermore, I don't see how Ada.Real_Time is a solution; that package's > purpose is, I think, to provide a better way to measure time *intervals* > with a higher resolution, but it doesn't do all that well with absolute > time (the RM says that Real_Time is considered relative to an undefined > "epoch" that could be the last system boot time). So I don't see how it > could be involved in a solution to this particular problem. Ada.Real_Time.Time is not a full solution. It only provides sane time arithmetic, e.g. "+", "-". A numeric type could do this as well. Ada.Calendar.Time cannot give even that little. You could not define arithmetical operations on it in any reasonable way. This is of course because of time skews, which make some values non-existent and some values repeating. I presume that any Ada implementation of it is broken in this or other way, which is irrelevant here, because there is no way to have arithmetic on something that is not additive anyway. I posted a couple examples for CET on the topic to Ada Comments some time ago. So the rule is: do not do any computations with Ada.Calendar.Time. Ada RM simply does not define the outcome. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de