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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cfd23c10fd537a80 X-Google-Attributes: gid103376,public From: Geoff Bull Subject: Re: C date package Date: 2000/05/10 Message-ID: <3918BB77.693C70D6@research.canon.com.au>#1/1 X-Deja-AN: 621374630 Content-Transfer-Encoding: 7bit References: <39176D85.603D7AEC@research.canon.com.au> <39178DEA.FD2C20FA@research.canon.com.au> <8f92o1$6v$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@research.canon.com.au X-Trace: cass.research.canon.com.au 957922128 29622 203.12.174.227 (10 May 2000 01:28:48 GMT) Organization: Canon Information Systems Research Australia Mime-Version: 1.0 NNTP-Posting-Date: 10 May 2000 01:28:48 GMT Newsgroups: comp.lang.ada Date: 2000-05-10T01:28:48+00:00 List-Id: Oops, I posted to comp.lang.ada by mistake! This was a thread on team-ada discussing which started with the "2038 bug". Robert Dewar wrote: > > In article <39178DEA.FD2C20FA@research.canon.com.au>, > Geoff Bull wrote: > > > The current Ada.Calendar is pretty weak - just reports an > > implementation defined time - local time on my system. > > Well that seems pretty strong to me, given that the design point > of the Ada.Calendar package is precisely to report the commonly > used local time on your system. > > Almost any package is weak if you start expecting it to do > things completely outside what it was designed for Fair enough, weak was probably the wrong word (maybe I should used "basic") - it doesn't even split out hours and minutes. And it would be reasonable to believe that anything in the Ada standard meets the design goals. But I don't even see where the RM says it reports local time, UTC UT1, TAI or whatever. Of course this is documented, as required, in the Gnat reference manual. 9.6 23.The time base associated with the type Time of package Calendar is implementation defined. 9.6 24.The functions Year, Month, Day, and Seconds return the corresponding values for a given value of the type Time, as appropriate to an implementation-defined timezone. So if I run two different Ada compilers on my system they are quite within their rights to report different times. A function that reported the offset from UTC, e.g., would be useful. I guess implementations that didn't know about timezones would have to be permitted to always return 0. It would be a bit much to ask for the weekday name when ther is no awareness of the current locale. Cheers Geoff