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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d1f23f0bd3971bec X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Timing Block of GNAT code in milliseconds Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net> Date: Fri, 29 Apr 2005 21:19:46 +0200 Message-ID: NNTP-Posting-Date: 29 Apr 2005 21:19:41 MEST NNTP-Posting-Host: 61328968.newsread4.arcor-online.net X-Trace: DXC=8mVHEfF7?\DRG:gi]CKmZG:ejgIfPPldDjW\KbG]kaMHliQbn6H@_EI^[gJemfNOhF[6LHn;2LCVNCOgUkn_?_YOS\Neh998[]L X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:10828 Date: 2005-04-29T21:19:41+02:00 List-Id: On Fri, 29 Apr 2005 13:25:23 -0500, tmoran@acm.org wrote: >>idea of synchronized time stamps cannot be expressed in Ada terms. > I would argue your problem is due to using a Calendar (or Real_Time) > that thinks it's running on a single machine. True > Can you replace the library > body with one that goes to a single time source for Ada.Calendar.Clock? > (There's no requirement in the language that a call on Clock be fast ;) The problem is with the scope of clock readings. 1. Calendar.Clock time is valid only within its time zone, further it suffers jumps, and is unsuitable for evaluation of large time spans. To start with, who can predict all new time jumps governments will prescribe in coming 10 years? 2. Real_Time.Clock time is valid no longer next system boot. I think that Annex E should mandate a third time source. It need not to be synchronized with other two. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de