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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2b151131f90050ab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-29 07:35:54 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada, calendar, and daylight savings Date: Mon, 29 Oct 2001 09:35:54 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9rjpgd$ah1$1@nh.pace.co.uk> References: <3BDC97CE.8070304@acm.org> <3BDCD0A9.5010101@acm.org> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1004366157 10785 136.170.200.133 (29 Oct 2001 14:35:57 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 29 Oct 2001 14:35:57 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:15347 Date: 2001-10-29T14:35:57+00:00 List-Id: Remember that Ada was at least in part designed for embedded systems as its original target. Time on embedded hardware can have all sorts of ambiguous meanings and had they specified time in a manner stringent enough to satisfy the things you are describing, it might not have been possible to implement it on some embedded platforms. Lots of embedded machines might count time as a certain number of clock ticks from when they were turned on and might have no particular need to actually be in synch with any other machines. Time might be relative to some starting epoch rather than normal calendar time. Or synchronization might be a matter of negotiation with a small network of other similar systems. Hence, requirements for the package Calendar might be a little loose for some applications. If Ada.Calendar and Ada.Real_Time don't provide all of the features you think that Ada might need, perhaps this could be a candidate package for an Ada standard component library. You might consider writing a specification as a proposal for what such a package should look like. Or propose some existing package you know of that might fit the needs. DMC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Corey Minyard" wrote in message news:3BDCD0A9.5010101@acm.org... > > If only life were so simple. I'm actually fairly familiar with how time > works, I was wondering if there was any standard besides the vague > statements made in the RM, maybe something buried in the AARM that > compiler vendors implemented. > > All systems that do a decent job handling time store the time in GMT and > convert based upon timezone, DST, etc. This way, you can correctly > determine everything about the time and handle it in a portable manner. > > Two basic problems I see with the way Ada time works: > > * DST will cause problems, because you cannot print the time and be 100% > sure it is unambiguous. This is more of a problem than you might > think when you have automated systems that take information and > process it. Every once in a while you will get wierd glitches. > > * You cannot communicate using time with other systems, because you > don't know if your local time is DST, what your GMT offset is, and > thus you cannot determine what your local time really is or how to > relate that to the time at another location. > > In other words, Ada.Calendar is not useful for operating in a > geographically distributed heterogeneous system where you have to > coordinate times. >