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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f3f07e9e53bcc4f6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-24 07:58:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!fu-berlin.de!uni-berlin.de!62.67.80.15!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: FILETIME <-> Ada.Real_Time.Time conversions Date: Mon, 24 Dec 2001 15:59:00 GMT Message-ID: <3c274c05.3132920@news.cis.dfn.de> References: <3c22f147.173527453@News.CIS.DFN.DE> NNTP-Posting-Host: 62.67.80.15 X-Trace: fu-berlin.de 1009209518 20314003 62.67.80.15 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:18280 Date: 2001-12-24T15:59:00+00:00 List-Id: On Fri, 21 Dec 2001 18:17:17 GMT, tmoran@acm.org wrote: >> It is clear that the time stamps shall be in UTC. >Hardly, because >> Ada.Calendar.Time is of no use, because it might be a political time. > If the distributed machines want to know what their compatriots >think the time is, they need to get synchronized (periodically) and >then use their change in Ada.Real_Time.Clock to estimate the change >in other machines' Ada.Real_Time.Clock UTC time is irrelevant. Our system allows many different scenarios. One of them is that both participants have some sort of external clock available. It is also well possible that they just cannot directly synchronize clocks because the connection is too bad for this. In the cases like that there must be an absolute time format for time stamps. UTC is a good candidate for it. The result of Ada.Real_Time.Split could be also acceptable *if* the epoch were fixed. > You and I could both note what our watches say when the ball >drops in NY Times Square when they celebrate New Years. We can >both agree to do something when our watches say 180 days have passed. >Neither of us need worry about what the UTC time is when the ball >drops, or what it is 180 days later. Yes, now let's imagine that the ball fell 1 Jan 1601 in Greenwich. That would be UTC. The time base is irrelevant, but it must be one. >>Ada.Real_Time.Time is well correlated with UTC, but there is no way to >>convert one to other. > Package Ada.Calendar does that all the time. Inside the computer is >an electronic counter - an Ada.Real_Time kind of thing. When you set >the time on your system, you are telling it that a counter value of >nnnn corresponds to a time of MM/DD/YY HH:MM:SS.ddd. Given the >difference between that and any other counter value, the frequency of >the counter, and some political information about daylight savings >time, Ada.Calendar.Split does some divisions and mods by 60, 24, and >the number of days in various months in various years, and comes up >with the MM/DD/YY HH:MM:SS.DD corresponding to the new counter value. This is why Ada.Calendar.Time is of so little use. Its time base depends on the place on Earth where the computer is currently located. When Ada.Calendar.Split tells me MM/DD/YY HH:MM:SS.DD I still cannot use this information without knowing the computer location and local rules regarding time faking. Regards, Dmitry Kazakov