* Timing Block of GNAT code in milliseconds @ 2005-04-21 13:28 markp 2005-04-21 18:00 ` tmoran 0 siblings, 1 reply; 19+ messages in thread From: markp @ 2005-04-21 13:28 UTC (permalink / raw) I am trying to time a block of code down to the millisecond level. Can anyone help in this area? Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-21 13:28 Timing Block of GNAT code in milliseconds markp @ 2005-04-21 18:00 ` tmoran 2005-04-21 18:53 ` markp 2005-04-22 1:00 ` Steve 0 siblings, 2 replies; 19+ messages in thread From: tmoran @ 2005-04-21 18:00 UTC (permalink / raw) >I am trying to time a block of code down to the millisecond level. Can >anyone help in this area? The traditional way is T0 := Ada.Calendar.Clock; for i in 1 .. 1000 loop -- code to be timed end loop; Result := (Ada.Calendar.Clock - T0)/1000; If the code to be timed is short so the loop overhead is significant, then you time an empty loop (making sure the compiler doesn't optimize it away) and subtract that. On Windows machines it doesn't take long to call Ada.Calendar.Clock, and that's accurate to better than one microsecond, so if you want millisecond accuracy you could even dispense with the loop and just do T0 := Ada.Calendar.Clock; -- code to be timed Result := (Ada.Calendar.Clock - T0)/1000; ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-21 18:00 ` tmoran @ 2005-04-21 18:53 ` markp 2005-04-21 19:40 ` Marc A. Criley 2005-04-21 19:44 ` Simon Wright 2005-04-22 1:00 ` Steve 1 sibling, 2 replies; 19+ messages in thread From: markp @ 2005-04-21 18:53 UTC (permalink / raw) Thanks for your response: I tried this and got some errors. Hereis what my code looks like My_Time : Ada.Calendar.Time; Result : Ada.Calendar.Time; My_Time := Ada.Calendar.Clock; Result := (Ada.Calendar.Clock - My_Time)/1000; The error I get is : Expected private type Ada.Calendar.Time Expected type Standard Duration on the piece of code (Ada.Calendar.Clock - My_Time). Lastly, How would I print out Result? Thanks again ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-21 18:53 ` markp @ 2005-04-21 19:40 ` Marc A. Criley 2005-04-21 19:44 ` Simon Wright 1 sibling, 0 replies; 19+ messages in thread From: Marc A. Criley @ 2005-04-21 19:40 UTC (permalink / raw) markp wrote: > I tried this and got some errors. Hereis what my code looks like > > My_Time : Ada.Calendar.Time; > Result : Ada.Calendar.Time; Result should by declared to be of type Duration, just like the error message said. > > My_Time := Ada.Calendar.Clock; > Result := (Ada.Calendar.Clock - My_Time)/1000; > > The error I get is : > > Expected private type Ada.Calendar.Time > Expected type Standard Duration > > on the piece of code (Ada.Calendar.Clock - My_Time). > > Lastly, > > How would I print out Result? Put_Line(Duration'Image(Result)); Marc A. Criley www.mckae.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-21 18:53 ` markp 2005-04-21 19:40 ` Marc A. Criley @ 2005-04-21 19:44 ` Simon Wright 1 sibling, 0 replies; 19+ messages in thread From: Simon Wright @ 2005-04-21 19:44 UTC (permalink / raw) "markp" <markwork66@yahoo.com> writes: > Thanks for your response: > > I tried this and got some errors. Hereis what my code looks like > > My_Time : Ada.Calendar.Time; > Result : Ada.Calendar.Time; > > My_Time := Ada.Calendar.Clock; > Result := (Ada.Calendar.Clock - My_Time)/1000; > > The error I get is : > > Expected private type Ada.Calendar.Time > Expected type Standard Duration > > on the piece of code (Ada.Calendar.Clock - My_Time). You need to say use type Ada.Calendar.Time; in a declarative region (I usually put this just before the 'begin'). That gives you access to the operation "-" taking two parameters of type Ada.Calendar.Time and returning a Duration; your Result should be of type Duration (a Time corresponds to the wall-clock time, whereas Duration is an interval). The error message you got is reasonable; if you subtract "4 Jan 2004" from "4 Jan 2005", you get "1 year" not "1 Jan 1971"! > Lastly, > > How would I print out Result? Did you say what compiler/platform you're using? On any platform you can say (eg) Ada.Text_IO.Put_Line ("Result is " & Duration'Image (Result)); GNAT has the non-portable extension 'Img so you can say Ada.Text_IO.Put_Line ("Result is " & Result'Img); -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-21 18:00 ` tmoran 2005-04-21 18:53 ` markp @ 2005-04-22 1:00 ` Steve 2005-04-23 5:39 ` Simon Wright 1 sibling, 1 reply; 19+ messages in thread From: Steve @ 2005-04-22 1:00 UTC (permalink / raw) Actually I think this is a better job for Ada.Real_Time than Ada.Calendar. I usually do something like: start_time := Ada.Real_Time.Clock; .. do something end_time := Ada.Real_Time.Clock; elapsed_seconds := Float( To_Duration( end_time - start_time ) ); I tend to think of the Real_Time package as the one to use when you are timing events and the Calendar package as the one to use when you don't care about precise timing and want the time of day for reporting, etc. Steve (The Duck) <tmoran@acm.org> wrote in message news:HI2dnf8gWoC-d_rfRVn-sQ@comcast.com... > >I am trying to time a block of code down to the millisecond level. Can >>anyone help in this area? > The traditional way is > T0 := Ada.Calendar.Clock; > for i in 1 .. 1000 loop > -- code to be timed > end loop; > Result := (Ada.Calendar.Clock - T0)/1000; > If the code to be timed is short so the loop overhead is significant, then > you time an empty loop (making sure the compiler doesn't optimize it away) > and subtract that. On Windows machines it doesn't take long to call > Ada.Calendar.Clock, and that's accurate to better than one microsecond, so > if you want millisecond accuracy you could even dispense with the loop and > just do > T0 := Ada.Calendar.Clock; > -- code to be timed > Result := (Ada.Calendar.Clock - T0)/1000; ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-22 1:00 ` Steve @ 2005-04-23 5:39 ` Simon Wright 2005-04-23 17:49 ` Steve 0 siblings, 1 reply; 19+ messages in thread From: Simon Wright @ 2005-04-23 5:39 UTC (permalink / raw) "Steve" <nospam_steved94@comcast.net> writes: > I tend to think of the Real_Time package as the one to use when you > are timing events and the Calendar package as the one to use when > you don't care about precise timing and want the time of day for > reporting, etc. It used to be the case with GNAT that there was an amazing similarity between these two clocks! Looking on 5.02a1, on a first glance it seems that Real_Time is derived as follows (the first two letters are the encoding in the distribution, eg if building on NT the file s-taprop.adb is copied from 5wtaprop.adb). 1s VxWorks/Cert taprop uses tickGet. 56 LynxOS taprop uses clock_gettime. 5a DEC Unix taprop uses clock_gettime. 5f IRIX pthread taprop uses clock_gettime. 5g IRIX athread taprop uses gettimeofday. 5h HP-UX DCE taprop uses clock_gettime. 5i GNU/LinuxThreads taprop uses getttimeofday. 5n Non-tasking taprop returns 0.0. 5o OS/2 taprop uses osprim which is the same as its Clock which is its system clock. 5p OpenNT, Dec Unix, SCO taprop use osprim which is the same as its Clock which uses gettimeofday. 5s Solaris taprop uses osprim which is the same as its Clock which uses gettimeofday. 5v OpenVMS/Alpha taprop uses osprim which is the same as its clock which uses the system clock. 5w NT taprop uses osprim which uses the performance counter. 5z VxWorks taprop uses clock_gettime. 7s 'POSIX-like' taprop uses clock_gettime. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-23 5:39 ` Simon Wright @ 2005-04-23 17:49 ` Steve 2005-04-24 18:57 ` Simon Wright 0 siblings, 1 reply; 19+ messages in thread From: Steve @ 2005-04-23 17:49 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:x7vsm1i2gs7.fsf@smaug.pushface.org... > "Steve" <nospam_steved94@comcast.net> writes: > >> I tend to think of the Real_Time package as the one to use when you >> are timing events and the Calendar package as the one to use when >> you don't care about precise timing and want the time of day for >> reporting, etc. > > It used to be the case with GNAT that there was an amazing similarity > between these two clocks! Looking on 5.02a1, on a first glance it > seems that Real_Time is derived as follows (the first two letters are > the encoding in the distribution, eg if building on NT the file > s-taprop.adb is copied from 5wtaprop.adb). > [snip] It would also be interesting to know whether there is a difference in the time base for Ada.Calendar and Ada.Real_Time for the different systems. Steve (The Duck) > > -- > Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-23 17:49 ` Steve @ 2005-04-24 18:57 ` Simon Wright 2005-04-24 20:05 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: Simon Wright @ 2005-04-24 18:57 UTC (permalink / raw) "Steve" <nospam_steved94@comcast.net> writes: > "Simon Wright" <simon@pushface.org> wrote in message > news:x7vsm1i2gs7.fsf@smaug.pushface.org... > > "Steve" <nospam_steved94@comcast.net> writes: > > > >> I tend to think of the Real_Time package as the one to use when > >> you are timing events and the Calendar package as the one to use > >> when you don't care about precise timing and want the time of day > >> for reporting, etc. > > > > It used to be the case with GNAT that there was an amazing > > similarity between these two clocks! Looking on 5.02a1, on a first > > glance it seems that Real_Time is derived as follows (the first > > two letters are the encoding in the distribution, eg if building > > on NT the file s-taprop.adb is copied from 5wtaprop.adb). > > > [snip] > > It would also be interesting to know whether there is a difference > in the time base for Ada.Calendar and Ada.Real_Time for the > different systems. There are two things, the tick rate and the epoch. All the ones that use the system clock or gettimeofday or clock_gettime are going to have identical Calendar and Real_Time (and, incidentally, fail to meet the ARM requirement in D.8(32), "There shall be no backward clock jumps.", if the system's time-of-day changes; the only one that obviously meets that is VxWorks/Cert). I don't know about Windows NT. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-24 18:57 ` Simon Wright @ 2005-04-24 20:05 ` Dmitry A. Kazakov 2005-04-25 22:56 ` Randy Brukardt 2005-04-28 20:26 ` Simon Wright 0 siblings, 2 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2005-04-24 20:05 UTC (permalink / raw) On 24 Apr 2005 19:57:24 +0100, Simon Wright wrote: > "Steve" <nospam_steved94@comcast.net> writes: > >> "Simon Wright" <simon@pushface.org> wrote in message >> news:x7vsm1i2gs7.fsf@smaug.pushface.org... >>> "Steve" <nospam_steved94@comcast.net> writes: >>> >>>> I tend to think of the Real_Time package as the one to use when >>>> you are timing events and the Calendar package as the one to use >>>> when you don't care about precise timing and want the time of day >>>> for reporting, etc. >>> >>> It used to be the case with GNAT that there was an amazing >>> similarity between these two clocks! Looking on 5.02a1, on a first >>> glance it seems that Real_Time is derived as follows (the first >>> two letters are the encoding in the distribution, eg if building >>> on NT the file s-taprop.adb is copied from 5wtaprop.adb). >>> >> [snip] >> >> It would also be interesting to know whether there is a difference >> in the time base for Ada.Calendar and Ada.Real_Time for the >> different systems. > > There are two things, the tick rate and the epoch. All the ones that > use the system clock or gettimeofday or clock_gettime are going to > have identical Calendar and Real_Time (and, incidentally, fail to meet > the ARM requirement in D.8(32), "There shall be no backward clock > jumps.", if the system's time-of-day changes; the only one that > obviously meets that is VxWorks/Cert). Yes, but that shouldn't prevent them from using the same source. They could run synchronized, experiencing rare and short periods when Calendar jumps here and there. > I don't know about Windows NT. I presume Real_Time uses Windows' performance counter which never jumps. But I have no idea how Calendar behaves, especially in presence of some external time synchronization software like NTP. Alas, both clock models are quite useless in a distributed environment. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-24 20:05 ` Dmitry A. Kazakov @ 2005-04-25 22:56 ` Randy Brukardt 2005-04-28 20:26 ` Simon Wright 1 sibling, 0 replies; 19+ messages in thread From: Randy Brukardt @ 2005-04-25 22:56 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:ei2meksw8if6.11hcrgpc1osq5$.dlg@40tude.net... > On 24 Apr 2005 19:57:24 +0100, Simon Wright wrote: ... > > I don't know about Windows NT. > > I presume Real_Time uses Windows' performance counter which never jumps. > But I have no idea how Calendar behaves, especially in presence of some > external time synchronization software like NTP. They both use the Window's performance counter; the code is shared as I recall. The base time is determined from the usual Windows system calls, and the performance counter is used to provide an offset. But the performance counter can jump - just that it does so forward. GNAT has a workaround for that, but of course you lose some accuracy if it has to use the workaround. Randy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-24 20:05 ` Dmitry A. Kazakov 2005-04-25 22:56 ` Randy Brukardt @ 2005-04-28 20:26 ` Simon Wright 2005-04-29 8:11 ` Dmitry A. Kazakov 1 sibling, 1 reply; 19+ messages in thread From: Simon Wright @ 2005-04-28 20:26 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > I presume Real_Time uses Windows' performance counter which never > jumps. But I have no idea how Calendar behaves, especially in > presence of some external time synchronization software like NTP. > > Alas, both clock models are quite useless in a distributed > environment. I think that's going a bit far -- it has to depend what your requirements are! We are running on plain VxWorks and need millisecond sync over our local network. If GNAT separated Real_Time from Calendar we could probably have used Calendar; as it is we have our own similar package which manages an offset from Calendar. Any requirement much finer than millisecond sync is going to need something more appropriate than plain old ethernet with a plain old network stack (which takes about 150 us to traverse on this hardware in the best of conditions!) -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-28 20:26 ` Simon Wright @ 2005-04-29 8:11 ` Dmitry A. Kazakov 2005-04-29 18:25 ` tmoran 2005-04-29 20:52 ` Randy Brukardt 0 siblings, 2 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2005-04-29 8:11 UTC (permalink / raw) On 28 Apr 2005 21:26:00 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> I presume Real_Time uses Windows' performance counter which never >> jumps. But I have no idea how Calendar behaves, especially in >> presence of some external time synchronization software like NTP. >> >> Alas, both clock models are quite useless in a distributed >> environment. > > I think that's going a bit far -- it has to depend what your > requirements are! > > We are running on plain VxWorks and need millisecond sync over our > local network. If GNAT separated Real_Time from Calendar we could > probably have used Calendar; as it is we have our own similar package > which manages an offset from Calendar. > > Any requirement much finer than millisecond sync is going to need > something more appropriate than plain old ethernet with a plain old > network stack (which takes about 150 us to traverse on this hardware > in the best of conditions!) Neither clock is usable in a WAN. We need time stamps synchronized across the network. The accuracy of synchronization is the second problem. The first problem is that the very idea of synchronized time stamps cannot be expressed in Ada terms. There is no portable way to get say UTC from either Calendar or Real_Time, or to convert UTC to them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 8:11 ` Dmitry A. Kazakov @ 2005-04-29 18:25 ` tmoran 2005-04-29 19:19 ` Dmitry A. Kazakov 2005-04-29 20:52 ` Randy Brukardt 1 sibling, 1 reply; 19+ messages in thread From: tmoran @ 2005-04-29 18:25 UTC (permalink / raw) >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. 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 ;) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 18:25 ` tmoran @ 2005-04-29 19:19 ` Dmitry A. Kazakov 2005-04-29 20:24 ` tmoran 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2005-04-29 19:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 19:19 ` Dmitry A. Kazakov @ 2005-04-29 20:24 ` tmoran 2005-04-30 9:47 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: tmoran @ 2005-04-29 20:24 UTC (permalink / raw) > 2. Real_Time.Clock time is valid no longer next system boot. Why? You could surely have a single black box located, say, in Greenwich England, which could be queried for time over the internet. Then you make a body for Real_Time.Clock that does that query to provide a time. All of your programs on all of your distributed programs use the same library so they query the same box and get the same time. The duration of a call to such a Real_Time.Clock might be long and might be variable, but that's true to some extent just running on a single multi-tasking machine. If you want something faster and less variable, have each machine read from a time continually transmitted over a fiber optic cable from a central source. There's no requirement that Ada.Real_Time use whatever low quality clock is provided by the particular computer it's running on. That just happens to be simpler, and adequate for most uses. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 20:24 ` tmoran @ 2005-04-30 9:47 ` Dmitry A. Kazakov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2005-04-30 9:47 UTC (permalink / raw) On Fri, 29 Apr 2005 15:24:27 -0500, tmoran@acm.org wrote: >> 2. Real_Time.Clock time is valid no longer next system boot. > Why? You could surely have a single black box located, say, in Greenwich > England, which could be queried for time over the internet. So it will be until next black box boot. (:-)) > Then you make > a body for Real_Time.Clock that does that query to provide a time. All of > your programs on all of your distributed programs use the same library so > they query the same box and get the same time. The duration of a call to > such a Real_Time.Clock might be long and might be variable, but that's > true to some extent just running on a single multi-tasking machine. If > you want something faster and less variable, have each machine read from a > time continually transmitted over a fiber optic cable from a central > source. There's no requirement that Ada.Real_Time use whatever low > quality clock is provided by the particular computer it's running on. > That just happens to be simpler, and adequate for most uses. There are enough time service departments all over the world to create a new one (per each application.) Why not to follow international standards? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 8:11 ` Dmitry A. Kazakov 2005-04-29 18:25 ` tmoran @ 2005-04-29 20:52 ` Randy Brukardt 2005-04-30 10:02 ` Dmitry A. Kazakov 1 sibling, 1 reply; 19+ messages in thread From: Randy Brukardt @ 2005-04-29 20:52 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net... ... > We need time stamps synchronized across the network. The accuracy of > synchronization is the second problem. The first problem is that the very > idea of synchronized time stamps cannot be expressed in Ada terms. There is > no portable way to get say UTC from either Calendar or Real_Time, or to > convert UTC to them. Of course there is (assuming that you have a compiler that supports the Ada 2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages). declare Now : Ada.Calendar.Time := Ada.Calendar.Clock; UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset := Ada.Calendar.Time_Zones.UTC_Time_Offset (Now); begin Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other parts of the UTC time>); ... end; It's a bit clunky, but that is the price of undoing daylight savings time. If your time period is short enough (doesn't cross any hour boundaries in the early morning), you can just get the offset once. And you can use Time_Of with a Time_Zone parameter to construct a value. Randy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Timing Block of GNAT code in milliseconds 2005-04-29 20:52 ` Randy Brukardt @ 2005-04-30 10:02 ` Dmitry A. Kazakov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2005-04-30 10:02 UTC (permalink / raw) On Fri, 29 Apr 2005 15:52:55 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net... > ... >> We need time stamps synchronized across the network. The accuracy of >> synchronization is the second problem. The first problem is that the very >> idea of synchronized time stamps cannot be expressed in Ada terms. There is >> no portable way to get say UTC from either Calendar or Real_Time, or to >> convert UTC to them. > > Of course there is (assuming that you have a compiler that supports the Ada > 2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages). > > declare > Now : Ada.Calendar.Time := Ada.Calendar.Clock; > UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset := > Ada.Calendar.Time_Zones.UTC_Time_Offset (Now); > begin > Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other > parts of the UTC time>); I do hope that there is a Time_Zone which does mangle time! > ... > end; > > It's a bit clunky, but that is the price of undoing daylight savings time. > If your time period is short enough (doesn't cross any hour boundaries in > the early morning), you can just get the offset once. > > And you can use Time_Of with a Time_Zone parameter to construct a value. It is a perversion. It is local political time which is derived from UTC not otherwise. Then the time span mandated by Ada.Calendar is too short, precision is too low (for time stamping accuracy is not an issue.) BTW I think we could safely replace Ada.Calendar.Clock with UTC clock, but that would make some elder Ada library implementations illegal. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-04-30 10:02 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-04-21 13:28 Timing Block of GNAT code in milliseconds markp 2005-04-21 18:00 ` tmoran 2005-04-21 18:53 ` markp 2005-04-21 19:40 ` Marc A. Criley 2005-04-21 19:44 ` Simon Wright 2005-04-22 1:00 ` Steve 2005-04-23 5:39 ` Simon Wright 2005-04-23 17:49 ` Steve 2005-04-24 18:57 ` Simon Wright 2005-04-24 20:05 ` Dmitry A. Kazakov 2005-04-25 22:56 ` Randy Brukardt 2005-04-28 20:26 ` Simon Wright 2005-04-29 8:11 ` Dmitry A. Kazakov 2005-04-29 18:25 ` tmoran 2005-04-29 19:19 ` Dmitry A. Kazakov 2005-04-29 20:24 ` tmoran 2005-04-30 9:47 ` Dmitry A. Kazakov 2005-04-29 20:52 ` Randy Brukardt 2005-04-30 10:02 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox