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: a07f3367d7,59c3b3f9911c9191 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.205.139.2 with SMTP id iu2mr4564766bkc.7.1343156988237; Tue, 24 Jul 2012 12:09:48 -0700 (PDT) Path: m12ni23617bkm.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Ada.Calendar and NTP (and Unix Epoch) Date: Tue, 24 Jul 2012 12:07:52 -0700 (PDT) Organization: http://groups.google.com 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> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1343156988 26217 127.0.0.1 (24 Jul 2012 19:09:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 24 Jul 2012 19:09:48 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-07-24T12:07:52-07:00 List-Id: 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: >=20 > > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1= /1/1901.=20 > > 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 mid= night > > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone = =3D> > > Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct m= e if > > I'm supposed to negate the value.) >=20 > 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 solv= e a specific problem. The specific problem (as I understood it) was this: You have an integer va= lue that represents a specific *point* *in* *time* T1 by specifying the num= ber of seconds that have elapsed since midnight on New Years Day in Greenwi= ch. You have another value that was returned by Ada.Calendar.Clock at some= other point in time T2. My contention is that you can create an Ada.Calen= dar.Time value to represent T1 by using Ada.Calendar.Formatting.Time_Of wit= h a suitable Time_Offset, and using the "+" functions defined in Ada.Calend= ar and Ada.Calendar.Formatting, that produces an Ada.Calendar.Time value re= presenting T1 that can correctly be compared with T2 (and subtracted to pro= duce a Duration). Do you believe my contention is incorrect? If so, please demonstrate. It's true, as you say, that UTC_Time_Offset's result isn't constant, and ch= anges when the time zone goes in and out of Daylight Savings Time. The poi= nt is, I was trying to use it in a way that would cancel out the effect of = that, producing a result in which the "offsets" factored into the two Ada.C= alendar.Time values being compared are the same, which means that you can c= ompare or subtract them correctly, regardless of whether the offsets would = be different if you ran the program six months from now. I may have done i= t wrong, but I don't believe it is impossible. If it is, please show why. There are certainly a lot of things that are difficult to get right with Ad= a.Calendar for some of the reasons you state. I don't think any of those a= re relevant to solving *this* particular problem. Furthermore, I don't see= how Ada.Real_Time is a solution; that package's purpose is, I think, to pr= ovide a better way to measure time *intervals* with a higher resolution, bu= t it doesn't do all that well with absolute time (the RM says that Real_Tim= e is considered relative to an undefined "epoch" that could be the last sys= tem boot time). So I don't see how it could be involved in a solution to t= his particular problem. -- Adam