* Re: Parameterised 'Image Attributes
2023-08-19 15:27 4% ` Jeffrey R.Carter
@ 2023-08-20 7:53 0% ` G.B.
0 siblings, 0 replies; 104+ results
From: G.B. @ 2023-08-20 7:53 UTC (permalink / raw)
On 19.08.23 17:27, Jeffrey R.Carter wrote:
> On 2023-08-19 11:14, J-P. Rosen wrote:
>> On 18/08/2023 08:18, Rod Kay wrote:
>>>
>>> Would it be possible/desirable to allow the 'Image attribute to have formatting parameters ? Something along the lines of ...
>>
>> The intent of the 'Image attribute is to have a quick representation, mainly for debugging purposes. If you want nice formatted output, use the Put procedure on String from Text_IO
> (...)
> The obvious solution is to have a library containing appropriate functions, which can be built around the Put procedures while still being functions. Such functions would need to be generic, unlike attribute functions which are automatically available for all types.
>
> The conflict between this common need and the minimal functionality provided by 'Image results in such requests. It seems desirable for the language to provide such functions, and extending the 'Image functions seems like a reasonable way for it to do so, regardless of the original intentions for the attribute.
So, also
- See how other languages address formats (good bits,
bad bits).
- Consider use cases.
- I/O is the program(mer)'s raison d'être. Can we easily Put
something into a stream without the help of a suitable
library?
Could there be a language defined type F whose purpose is to support
the description of formats? Objects of type F would "configure"
what 'Image does when computing a representation of a date, a number, ...
My_Length'Image (Arg => diameter, Format => ___);
Some use cases:
- I18n of number formats (cf ARM F.3), CHF 1'234'000.–
- Handle ubiquitous ISO formats of date-time (as mentioned below;
also cf. ARM 9.6.1)
- reporting,
- integrate own output with output of other system components
(a site-wide monitoring system searches outputs, say)
- fill in templates when these do not support formatting
- 'Input an object of type F at run-time, so that program's
use of 'Image can be changed according to customer's
local expectations.
- support the formalized exchange of "numerical" data in
heterogeneous systems, using text streams.
These use cases are about the O of I/O. By symmetry, it would be
nice to have implementations of Ada that support the I part of this
kind of I/O, I think, with work to be split between implementers
and programmers.
My_Length'Value (Arg => diameter, Format => ___);
Or perhaps multimethods that take a stream and a format
when they need to write a value?
> One library with such functions is the PragmAda Reusable Components (https://github.com/jrcarter/PragmARC). The package PragmARC.Images (https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-images.ads) provides such functions for integer and floating-point types. Function PragmARC.Images.Image is an instantiation for Standard.Integer.
>
> PragmARC.Date_Handler (https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-date_handler.ads) provides image functions for dates and times; although the language now provides a function for a date-time image, Date_Handler continues to be useful as it provides for customized formats rather than the single format provided by Ada.Calendar.Formatting. Many users also find the semantics of the latter's time-zone parameter to be confusing.
>
> (ISO/IEC 8652:2023 provides a date-time image function the returns the image for the local time zone, but as there are no compilers* for this version of the language, I don't consider that relevant.
^ permalink raw reply [relevance 0%]
* Re: Parameterised 'Image Attributes
@ 2023-08-19 15:27 4% ` Jeffrey R.Carter
2023-08-20 7:53 0% ` G.B.
0 siblings, 1 reply; 104+ results
From: Jeffrey R.Carter @ 2023-08-19 15:27 UTC (permalink / raw)
On 2023-08-19 11:14, J-P. Rosen wrote:
> On 18/08/2023 08:18, Rod Kay wrote:
>>
>> Would it be possible/desirable to allow the 'Image attribute to have
>> formatting parameters ? Something along the lines of ...
>
> The intent of the 'Image attribute is to have a quick representation, mainly for
> debugging purposes. If you want nice formatted output, use the Put procedure on
> String from Text_IO.
There is a common problem across many types and problem domains of having a
function that returns a string of an appropriate length representing a value of
the type with desired formatting. Common examples include numeric values, dates,
and times. The resulting string is usually combined with other information into
a message that may be stored in memory for a while, though it is rare for it not
to be output eventually. As an example, the message may be put on a protected
queue for later output by a logging task.
Ada 83 tended not to include anything that the developer could implement; there
was no math library or image functions for dates or times. The 'Image attribute
was provided, but is unsuited for most such uses.
The use of the Text_IO generic sub-pkg Put procedures that output to strings is
not convenient because they are procedures, not functions.
Later versions of Ada included more support for such needs, but not for numeric
values.
The obvious solution is to have a library containing appropriate functions,
which can be built around the Put procedures while still being functions. Such
functions would need to be generic, unlike attribute functions which are
automatically available for all types.
The conflict between this common need and the minimal functionality provided by
'Image results in such requests. It seems desirable for the language to provide
such functions, and extending the 'Image functions seems like a reasonable way
for it to do so, regardless of the original intentions for the attribute.
One library with such functions is the PragmAda Reusable Components
(https://github.com/jrcarter/PragmARC). The package PragmARC.Images
(https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-images.ads) provides
such functions for integer and floating-point types. Function
PragmARC.Images.Image is an instantiation for Standard.Integer.
PragmARC.Date_Handler
(https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-date_handler.ads)
provides image functions for dates and times; although the language now provides
a function for a date-time image, Date_Handler continues to be useful as it
provides for customized formats rather than the single format provided by
Ada.Calendar.Formatting. Many users also find the semantics of the latter's
time-zone parameter to be confusing.
(ISO/IEC 8652:2023 provides a date-time image function the returns the image for
the local time zone, but as there are no compilers* for this version of the
language, I don't consider that relevant.
(*A compiler for a version of the language implements the entire core language
of that version of the ARM.)
--
Jeff Carter
"The men get one hot meal a day: a bowl of steam."
Take the Money and Run
145
^ permalink raw reply [relevance 4%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-07 0:19 6% ` Randy Brukardt
@ 2020-03-07 1:18 6% ` Optikos
0 siblings, 0 replies; 104+ results
From: Optikos @ 2020-03-07 1:18 UTC (permalink / raw)
On Friday, March 6, 2020 at 6:19:20 PM UTC-6, Randy Brukardt wrote:
> "Optikos" wrote in message
> news:6c9347ec-8c2b-4a77-bdd8-a52b6f2d7858@googlegroups.com...
> ...
> >My point is that if Ada 2020's ISO/IEC is officially emitted the way that
> >so-called
> >Ada 2005's official amendment ISO/IEC8652:1995/Amd1:2007 to official
> >standard
> >ISO/IEC8652:1995 still in effect, then these binding AIs need to be
> >pursuant to not
> >only an ISO/IEC8652:2012/Amd1:2020 (or :2021) but also an
> >ISO/IEC8652:2012/Corr1:2020 (or 2021) to be retroactive back to 2012.
> >Hence,
> >it would be advantageous in this regard for the Ada 2005 model of mere
> >official
> >amendment to a still-in-effect prior standard to be avoided and the Ada
> >2012 model
> >to be enacted for Ada 2020.
>
> My understanding is that ISO has a limit of two modifying documents to any
> particular Standard before a revision is required. We already have a
> Corrigendum to the Ada 2012 standard, and adding a separate Corrigendum and
> Amendment would add two more, which would exceed the limit.
>
> So I don't believe this idea would be allowed. We might be able to get a
> waiver (once), but you're suggesting using it as a long-term strategy, and
> that wouldn't be allowed.
>
> Randy.
No, I am not making any such suggestion at all. Instead, I am suggesting that releasing Ada 2020 as a full-fledged standard instead of merely an amendment (as Ada 2005 was) fixes so many problems and mitigates so many complications, as described above, due to the new edition of the standard wiping the slate clean again without needing to retroactively maintain the Ada 2012 standard anymore.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-06 14:42 4% ` Optikos
@ 2020-03-07 0:19 6% ` Randy Brukardt
2020-03-07 1:18 6% ` Optikos
0 siblings, 1 reply; 104+ results
From: Randy Brukardt @ 2020-03-07 0:19 UTC (permalink / raw)
"Optikos" <ZUERCHER_Andreas@outlook.com> wrote in message
news:6c9347ec-8c2b-4a77-bdd8-a52b6f2d7858@googlegroups.com...
...
>My point is that if Ada 2020's ISO/IEC is officially emitted the way that
>so-called
>Ada 2005's official amendment ISO/IEC8652:1995/Amd1:2007 to official
>standard
>ISO/IEC8652:1995 still in effect, then these binding AIs need to be
>pursuant to not
>only an ISO/IEC8652:2012/Amd1:2020 (or :2021) but also an
>ISO/IEC8652:2012/Corr1:2020 (or 2021) to be retroactive back to 2012.
>Hence,
>it would be advantageous in this regard for the Ada 2005 model of mere
>official
>amendment to a still-in-effect prior standard to be avoided and the Ada
>2012 model
>to be enacted for Ada 2020.
My understanding is that ISO has a limit of two modifying documents to any
particular Standard before a revision is required. We already have a
Corrigendum to the Ada 2012 standard, and adding a separate Corrigendum and
Amendment would add two more, which would exceed the limit.
So I don't believe this idea would be allowed. We might be able to get a
waiver (once), but you're suggesting using it as a long-term strategy, and
that wouldn't be allowed.
Randy.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-05 23:29 5% ` Randy Brukardt
@ 2020-03-06 14:42 4% ` Optikos
2020-03-07 0:19 6% ` Randy Brukardt
0 siblings, 1 reply; 104+ results
From: Optikos @ 2020-03-06 14:42 UTC (permalink / raw)
On Thursday, March 5, 2020 at 5:29:35 PM UTC-6, Randy Brukardt wrote:
> Optikos wrote in message
> news:f94395b7-f2de-4c49-8edd-b24bfa64cc37@googlegroups.com...
> >On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
> >> "Simon Wright" wrote in message
> >> news:lyv9nl8p6w.fsf@pushface.org...
> >> ...
> >> > There was a conversation on Ada-Comment in June last year, in which it
> >> > turned out that compiler implementers may have have been
> >> > misinterpreting
> >> > the ARM. It was quite confusing.
> >>
> >> Not just a conversation, but also a Binding Interpretation AI (which
> >> therefore applies to Ada 2012 compilers), AI12-0336-1.
> >
> >Shouldn't these Binding AIs that take effect from a past edition of the ISO
> >standard onward (and not merely incorporated into Ada 2020 or Ada
> >202X post-2020) ..be an ISO/IEC corrigendum..? Allowing errata be
> >permanently published semi-officially in any forum other than
> >cummulatively in an official ISO/IEC corrigendum seems to be against the
> >ISO/IEC rules.
>
> Not necessarily. ISO has very strict limits on the number of Corrigenda that
> can be issued for a particular standard; after that the only choice is to
> update the Standard.
>
> Remember that from ISO's perspective older standards don't actually exist;
Well, there are a few finer points, for the interested reader. Remember that so-called Ada 2005 (officially ISO/IEC8652:1995/Amd1:2007) was merely an amendment is ISO/IEC-speak. If so-called Ada2020 is fashioned likewise as an amendment ISO/IEC8652:2012/Amd1:2020 (or :2021, instead of a new edition as Ada 2012 was as officially ISO/IEC8652:2012), then all the Binding AIs that are retroactive back to Ada 2012 would need an official ISO/IEC corrigendum no later than the official release date of Ada 2020's ISO/IEC standard document. But if Ada 2020 is released instead as a new edition (say, ISO/IEC8652:2020 or ISO/IEC8652:2021), then this new edition would eclipse the older ISO/IEC8652:2012 as you describe and no harm no foul to a not-corrigendumed ISO/IEC8652:2012 that got left in history because by the corrigendum's due-date it became a moot point due to :2012 no longer being the standard in effect.
> only the latest version is relevant to ISO. So the difference between
> non-Corrigendum Binding Interpretations and Amendments is non-existent to
> ISO.
Because ISO/IEC amendments, corrigendum, technical reports, and standards are well-regulated published documents, that sentence needs to be reworded to be correct: So the difference between
1) non-Corrigendum Binding-Interpretation AIs outside of ISO/IEC officially-published documents
and
2) any other recorded vote by the ARG on matters pursuant to the culmination in a forthcoming ISO/IEC document
is non-existent to ISO.
My point is that if Ada 2020's ISO/IEC is officially emitted the way that so-called Ada 2005's official amendment ISO/IEC8652:1995/Amd1:2007 to official standard ISO/IEC8652:1995 still in effect, then these binding AIs need to be pursuant to not only an ISO/IEC8652:2012/Amd1:2020 (or :2021) but also an ISO/IEC8652:2012/Corr1:2020 (or 2021) to be retroactive back to 2012. Hence, it would be advantageous in this regard for the Ada 2005 model of mere official amendment to a still-in-effect prior standard to be avoided and the Ada 2012 model to be enacted for Ada 2020.
> But as a practical matter, people continue to use older standards and they
> need corrections (not allowing implementers to fix language bugs would be
> worse; why would anyone want to implement nonsense?). Such users need
> guidance as well, as do the implementers.
>
> For ACATS purposes (which maintains testing all of the older standards
> except Ada 83), generally non-Corrigendum binding interpretations are
> optional for older standards, which means that either the original wording
> or the new wording is allowed. (We prefer the new wording, of course, but
> there's no mechanism to require it.) OTOH, Amendments are ignored for the
> purposes of testing older standards -- that's why we classify them
> differently.
But conversely unlike amendments, a corrigendum ISO/IEC8652:2012/Corr1:202X to ISO/IEC8652:2012 is normative retroactively to 2012 until ISO/IEC8652:2012 is supplanted by an ISO/IEC8652:202Y even if X and Y are different, say, for Ada 2029 being the next official edition of the standard ISO/IEC8652:2029 where Ada 2020 ended up (unwisely in my opinion) being a mere amendment ISO/IEC8652:2012/Amd1:2020 (or :2021) analogous to Ada 2005 being a mere amendment ISO/IEC8652:1995/Amd1:2007. This retroactive correction via a corrigendum matches this thread's intended normativeness of Binding AIs, whereas ISO/IEC's amendment term-of-art does not, avoiding general-purpose dictionary definitions of amendment, which might also have crept into this thread.
^ permalink raw reply [relevance 4%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-04 22:33 6% ` Optikos
2020-03-05 16:11 6% ` Optikos
@ 2020-03-05 23:29 5% ` Randy Brukardt
2020-03-06 14:42 4% ` Optikos
1 sibling, 1 reply; 104+ results
From: Randy Brukardt @ 2020-03-05 23:29 UTC (permalink / raw)
"Optikos" <ZUERCHER_Andreas@outlook.com> wrote in message
news:f94395b7-f2de-4c49-8edd-b24bfa64cc37@googlegroups.com...
>On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
>> "Simon Wright" wrote in message
>> news:lyv9nl8p6w.fsf@pushface.org...
>> ...
>> > There was a conversation on Ada-Comment in June last year, in which it
>> > turned out that compiler implementers may have have been
>> > misinterpreting
>> > the ARM. It was quite confusing.
>>
>> Not just a conversation, but also a Binding Interpretation AI (which
>> therefore applies to Ada 2012 compilers), AI12-0336-1.
>
>Shouldn't these Binding AIs that take effect from a past edition of the ISO
>standard onward (and not merely incorporated into Ada 2020 or Ada
>202X post-2020) ..be an ISO/IEC corrigendum..? Allowing errata be
>permanently published semi-officially in any forum other than
>cummulatively in an official ISO/IEC corrigendum seems to be against the
>ISO/IEC rules.
Not necessarily. ISO has very strict limits on the number of Corrigenda that
can be issued for a particular standard; after that the only choice is to
update the Standard.
Remember that from ISO's perspective older standards don't actually exist;
only the latest version is relevant to ISO. So the difference between
non-Corrigendum Binding Interpretations and Amendments is non-existent to
ISO.
But as a practical matter, people continue to use older standards and they
need corrections (not allowing implementers to fix language bugs would be
worse; why would anyone want to implement nonsense?). Such users need
guidance as well, as do the implementers.
For ACATS purposes (which maintains testing all of the older standards
except Ada 83), generally non-Corrigendum binding interpretations are
optional for older standards, which means that either the original wording
or the new wording is allowed. (We prefer the new wording, of course, but
there's no mechanism to require it.) OTOH, Amendments are ignored for the
purposes of testing older standards -- that's why we classify them
differently.
Randy.
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-04 22:33 6% ` Optikos
@ 2020-03-05 16:11 6% ` Optikos
2020-03-05 23:29 5% ` Randy Brukardt
1 sibling, 0 replies; 104+ results
From: Optikos @ 2020-03-05 16:11 UTC (permalink / raw)
On Wednesday, March 4, 2020 at 4:33:12 PM UTC-6, Optikos wrote:
> On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
> > "Simon Wright" wrote in message
> > news:lyv9nl8p6w.fsf@pushface.org...
> > ...
> > > There was a conversation on Ada-Comment in June last year, in which it
> > > turned out that compiler implementers may have have been misinterpreting
> > > the ARM. It was quite confusing.
> >
> > Not just a conversation, but also a Binding Interpretation AI (which
> > therefore applies to Ada 2012 compilers), AI12-0336-1.
>
> Shouldn't these Binding AIs that take effect from a past edition of the ISO standard onward (and not
> merely incorporated into Ada 2020 or Ada 202X post-2020) ••be an ISO/IEC corrigendum••? Allowing
> errata be permanently published semi-officially in any forum other than cummulatively in an official
> ISO/IEC corrigendum seems to be against the ISO/IEC rules.
I shouldn't have used the term “errata” there because it is a term-of-art for nontechnical grammatical/spelling errors and the minor like. I should have utilized ‘technical defect’ or some such term instead, because technical defects go in a corrigendum whereas purely-linguistic errors go in errata. The ambiguity of UTC vis a vis offsets therefrom in past editions of the ISO/IEC Ada standard are a defect in the meaning, not a mere linguistic-/syntactic-oops erratum.
https://blog.ansi.org/2016/09/standards-changes-amendment-corrigendum-errata
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-03 23:49 5% ` Randy Brukardt
2020-03-04 15:19 7% ` Simon Wright
@ 2020-03-04 22:33 6% ` Optikos
2020-03-05 16:11 6% ` Optikos
2020-03-05 23:29 5% ` Randy Brukardt
1 sibling, 2 replies; 104+ results
From: Optikos @ 2020-03-04 22:33 UTC (permalink / raw)
On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
> "Simon Wright" wrote in message
> news:lyv9nl8p6w.fsf@pushface.org...
> ...
> > There was a conversation on Ada-Comment in June last year, in which it
> > turned out that compiler implementers may have have been misinterpreting
> > the ARM. It was quite confusing.
>
> Not just a conversation, but also a Binding Interpretation AI (which
> therefore applies to Ada 2012 compilers), AI12-0336-1.
Shouldn't these Binding AIs that take effect from a past edition of the ISO standard onward (and not merely incorporated into Ada 2020 or Ada 202X post-2020) ••be an ISO/IEC corrigendum••? Allowing errata be permanently published semi-officially in any forum other than cummulatively in an official ISO/IEC corrigendum seems to be against the ISO/IEC rules.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-03 23:49 5% ` Randy Brukardt
@ 2020-03-04 15:19 7% ` Simon Wright
2020-03-04 22:33 6% ` Optikos
1 sibling, 0 replies; 104+ results
From: Simon Wright @ 2020-03-04 15:19 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> As Dmitry says, the default Time_Offset on GNAT gives one UTC. If you want
> CST or CDT (my time zones, which change on this coming Sunday), one needs to
> use -360 or -300. We've added a new renaming Local_Time_Image to make this
> relatively easy (dunno if GNAT has it yet).
FSF GCC 10.0.1 20200206 (experimental) doesn't. May make it into GNAT CE
2020.
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-03 14:53 13% ` Simon Wright
2020-03-03 17:40 7% ` Simon Wright
@ 2020-03-03 23:49 5% ` Randy Brukardt
2020-03-04 15:19 7% ` Simon Wright
2020-03-04 22:33 6% ` Optikos
1 sibling, 2 replies; 104+ results
From: Randy Brukardt @ 2020-03-03 23:49 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:lyv9nl8p6w.fsf@pushface.org...
...
> There was a conversation on Ada-Comment in June last year, in which it
> turned out that compiler implementers may have have been misinterpreting
> the ARM. It was quite confusing.
Not just a conversation, but also a Binding Interpretation AI (which
therefore applies to Ada 2012 compilers), AI12-0336-1.
Essentially, the formal definition of Time_Offset, and the way it was
actually implemented by every compiler except mine, was completely
different. We decided to match practice, especially as that matches the way
the Internet uses time offsets. So that part of the RM was rewritten.
As Dmitry says, the default Time_Offset on GNAT gives one UTC. If you want
CST or CDT (my time zones, which change on this coming Sunday), one needs to
use -360 or -300. We've added a new renaming Local_Time_Image to make this
relatively easy (dunno if GNAT has it yet).
The advantage of this definition is that the base UTC time doesn't jump
during the year, but if you are interested in local time, you have to
determine the offset based on the time-of-year.
Your example suggests that GNAT is doing something weird with times that are
far away from today. That's certainly not intended, sounds like a bug to me.
Certainly is a bug with the rewritten rules for Time_Image.
Randy.
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-03 14:53 13% ` Simon Wright
@ 2020-03-03 17:40 7% ` Simon Wright
2020-03-03 23:49 5% ` Randy Brukardt
1 sibling, 0 replies; 104+ results
From: Simon Wright @ 2020-03-03 17:40 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> There was a conversation on Ada-Comment in June last year, in which it
> turned out that compiler implementers may have have been misinterpreting
> the ARM. It was quite confusing.
Also, see AI95-00160,
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00160.txt?rev=1.4&raw=N
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-02 18:49 13% Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves
2020-03-02 23:08 7% ` Randy Brukardt
@ 2020-03-03 14:53 13% ` Simon Wright
2020-03-03 17:40 7% ` Simon Wright
2020-03-03 23:49 5% ` Randy Brukardt
1 sibling, 2 replies; 104+ results
From: Simon Wright @ 2020-03-03 14:53 UTC (permalink / raw)
Marius Amado-Alves <amado.alves@gmail.com> writes:
> Feeding Ada.Calendar.Formatting.Image with an Ada.Calendar.Time_Of the
> year, month, day, seconds on the left, we get the image on the
> right. Some images, marked *, are 1 hour behind.
>
> 2015 1 21 32040 ( 8:54 AM) => 2015-01-21 08:54:00
> 2015 1 21 39240 (10:54 AM) => 2015-01-21 10:54:00
> 2015 7 21 32040 ( 8:54 AM) => 2015-07-21 07:54:00 *
> 2015 7 21 39240 (10:54 AM) => 2015-07-21 09:54:00 *
>
> The different input is the month, January versus July, so it looks
> like a daylight savings thing. Is this expected behaviour? Thanks.
>
> [Compiler = GNAT Community 2018 (20180523-73)]
There was a conversation on Ada-Comment in June last year, in which it
turned out that compiler implementers may have have been misinterpreting
the ARM. It was quite confusing.
Part of the problem is that Ada.Calendar.Clock, implemented over the OS
facilities, may or may not be in local time; and how does it treat times
which are not in the 'now' time zone?
I wrote this:
with Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones;
with Ada.Text_IO;
procedure Marius is
use type Ada.Calendar.Time;
Earlier : constant Ada.Calendar.Time
:= Ada.Calendar.Time_Of (2015, 1, 21, 32040.0);
Later : constant Ada.Calendar.Time
:= Ada.Calendar.Time_Of (2015, 7, 21, 32040.0);
Offset_Earlier : constant Ada.Calendar.Time_Zones.Time_Offset
:= Ada.Calendar.Time_Zones.UTC_Time_Offset (Earlier);
Offset_Later : constant Ada.Calendar.Time_Zones.Time_Offset
:= Ada.Calendar.Time_Zones.UTC_Time_Offset (Later);
begin
Ada.Text_Io.Put_Line ("Earlier");
Ada.Text_IO.Put_Line
("UTC_Time_Offset: " & Offset_Earlier'Image);
Ada.Text_IO.Put_Line
("Time_Zone default: "
& Ada.Calendar.Formatting.Image (Earlier));
Ada.Text_IO.Put_Line
("Time_Zone offset: "
& Ada.Calendar.Formatting.Image (Earlier, Time_Zone => Offset_Earlier));
Ada.Text_IO.New_Line;
Ada.Text_IO.Put_Line ("Later");
Ada.Text_IO.Put_Line
("UTC_Time_Offset: " & Offset_Later'Image);
Ada.Text_IO.Put_Line
("Time_Zone default: "
& Ada.Calendar.Formatting.Image (Later));
Ada.Text_IO.Put_Line
("Time_Zone offset: "
& Ada.Calendar.Formatting.Image (Later, Time_Zone => Offset_Later));
end Marius;
and it appears that with GNAT (current free
versions), macOS Mojave, time zone London, Time_Of does something
mysterious;it seems that Time_Of looks at the time you specify (08:54)
and thinks to itself, "but the date part shows that's in DST, so the
local clock now (in GMT) would be reading 07:54"
$ ./marius
Earlier
UTC_Time_Offset: 0
Time_Zone default: 2015-01-21 08:54:00
Time_Zone offset: 2015-01-21 08:54:00
Later
UTC_Time_Offset: 60
Time_Zone default: 2015-07-21 07:54:00
Time_Zone offset: 2015-07-21 08:54:00
Just for fun, trying a different time zone (this may well NOT be the
same as actually being in that time zone :)
$ TZ=EST ./marius
Earlier
UTC_Time_Offset: -300
Time_Zone default: 2015-01-21 13:54:00
Time_Zone offset: 2015-01-21 08:54:00
Later
UTC_Time_Offset: -300
Time_Zone default: 2015-07-21 13:54:00
Time_Zone offset: 2015-07-21 08:54:00
Same results on Debian (running in a VM on this Macbook).
^ permalink raw reply [relevance 13%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-03 12:59 7% ` Marius Amado-Alves
@ 2020-03-03 14:25 5% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2020-03-03 14:25 UTC (permalink / raw)
On 2020-03-03 13:59, Marius Amado-Alves wrote:
> Thanks. I used the default, which is a zero offset, hence my surprise,
Zero means UTC, AFAIK. To get local time you should pass the result of
UTC_Time_Offset from Ada.Calendar.Time_Zones.
> but maybe I am misunderstanding something, date and time is such a complex matter.
Nothing complex, just messed up. The design as I understand it, because
ARM tells nothing about the meaning of Time values, is that you
interpret the value of Time differently in different time zones. It is
done by passing the time zone offset, which itself is a function of time
to add necessary confusion. So Time is kind of simultaneously UTC and
CET and whatever.
The common, sane (and scientific) understanding is that UTC and CET are
different times.
One of the consequences of present design is that you, for example,
could not store local time reading as a compound value. Without a time
offset it has no sense. You also cannot spell Jan 23, 2100 CET, as you
do not know which time offset it will possibly have in 80 years. CET is
a function and not a value. So there is a date and no time.
> (Namely, I dont understand how a "fixed" offset can vary throughout the year.)
Political time jumps twice a year, so the offset does. Formally these
are two different times, e.g. CET and CEST.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-02 23:08 7% ` Randy Brukardt
@ 2020-03-03 12:59 7% ` Marius Amado-Alves
2020-03-03 14:25 5% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Marius Amado-Alves @ 2020-03-03 12:59 UTC (permalink / raw)
Thanks. I used the default, which is a zero offset, hence my surprise, but maybe I am misunderstanding something, date and time is such a complex matter.
(Namely, I dont understand how a "fixed" offset can vary throughout the year.)
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
2020-03-02 18:49 13% Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves
@ 2020-03-02 23:08 7% ` Randy Brukardt
2020-03-03 12:59 7% ` Marius Amado-Alves
2020-03-03 14:53 13% ` Simon Wright
1 sibling, 1 reply; 104+ results
From: Randy Brukardt @ 2020-03-02 23:08 UTC (permalink / raw)
What time zone did you give Image? Time zones are dependent on the time
given, so just giving some constant is insufficient to give the correct
local time. (A "time zone" is an offset from UTC, so of course it differs
throughout the year for most localities.)
Randy.
"Marius Amado-Alves" <amado.alves@gmail.com> wrote in message
news:e92d8c8d-a182-4990-b3f6-33c2ab90bce9@googlegroups.com...
> Feeding Ada.Calendar.Formatting.Image with an Ada.Calendar.Time_Of the
> year, month, day, seconds on the left, we get the image on the right. Some
> images, marked *, are 1 hour behind.
>
> 2015 1 21 32040 ( 8:54 AM) => 2015-01-21 08:54:00
> 2015 1 21 39240 (10:54 AM) => 2015-01-21 10:54:00
> 2015 7 21 32040 ( 8:54 AM) => 2015-07-21 07:54:00 *
> 2015 7 21 39240 (10:54 AM) => 2015-07-21 09:54:00 *
>
> The different input is the month, January versus July, so it looks like a
> daylight savings thing. Is this expected behaviour? Thanks.
>
> [Compiler = GNAT Community 2018 (20180523-73)]
^ permalink raw reply [relevance 7%]
* Ada.Calendar.Formatting.Image (or Time_Of) changing the time
@ 2020-03-02 18:49 13% Marius Amado-Alves
2020-03-02 23:08 7% ` Randy Brukardt
2020-03-03 14:53 13% ` Simon Wright
0 siblings, 2 replies; 104+ results
From: Marius Amado-Alves @ 2020-03-02 18:49 UTC (permalink / raw)
Feeding Ada.Calendar.Formatting.Image with an Ada.Calendar.Time_Of the year, month, day, seconds on the left, we get the image on the right. Some images, marked *, are 1 hour behind.
2015 1 21 32040 ( 8:54 AM) => 2015-01-21 08:54:00
2015 1 21 39240 (10:54 AM) => 2015-01-21 10:54:00
2015 7 21 32040 ( 8:54 AM) => 2015-07-21 07:54:00 *
2015 7 21 39240 (10:54 AM) => 2015-07-21 09:54:00 *
The different input is the month, January versus July, so it looks like a daylight savings thing. Is this expected behaviour? Thanks.
[Compiler = GNAT Community 2018 (20180523-73)]
^ permalink raw reply [relevance 13%]
* Q: Calendar and time zones
@ 2019-04-30 0:58 7% b.mcguinness747
0 siblings, 0 replies; 104+ results
From: b.mcguinness747 @ 2019-04-30 0:58 UTC (permalink / raw)
Section 9.6.1 of the Reference Manual has a note (39) at the bottom of the page that says: "Calling Split on the results of subtracting Duration(UTC_Time_Offset*60) from Clock provides the components (hours, minutes, and so on) of the UTC time. In the United States, for example, UTC_Time_Offset will generally be negative."
But several versions of Split have a Time_Zone argument that defaults to 0, which I interpret as meaning that they default to reporting the time in UTC. Moreover, I wrote a test program that seems to report UTC time properly without subtracting a time zone offset:
with Ada.Calendar, Ada.Calendar.Formatting, Ada.Calendar.Time_Zones, Ada.Text_IO;
procedure timetest is
use Ada.Calendar, Ada.Calendar.Formatting, Ada.Calendar.Time_Zones;
now : Time := Clock;
zone_offset : Time_Offset := UTC_Time_Offset (now);
begin
Ada.Text_IO.Put_Line ("Current time: " & Image (now) & " UTC");
Ada.Text_IO.Put_Line ("Current time: " & Image (now, false, zone_offset) & " local");
Ada.Text_IO.Put_Line ("Time zone offset: " & Time_Offset'Image (zone_offset) & " minutes");
end timetest;
$ timetest
Current time: 2019-04-30 00:55:19 UTC
Current time: 2019-04-29 20:55:19 local
Time zone offset: -240 minutes
Perhaps the comment refers only to versions of Split that do not take a Time_Zone argument.
It would be helpful if the comment in the Reference Manual was rewritten in future editions to indicate more clearly what it means.
--- Brian McGuinness
^ permalink raw reply [relevance 7%]
* Re: How to run a GNAT program without starting a terminal session
@ 2018-07-18 1:33 7% ` Shark8
0 siblings, 0 replies; 104+ results
From: Shark8 @ 2018-07-18 1:33 UTC (permalink / raw)
On Tuesday, July 17, 2018 at 3:56:24 PM UTC-6, Jerry wrote:
With
Ada.Calendar.Formatting,
Ada.Text_IO;
Use
Ada.Text_IO;
Procedure Test is
Task Type Hello( Cycle_Timing : not null access Duration ) is
Entry Stop;
end Hello;
Task Body Hello is
Finished : Boolean := False;
Begin
Ada.Text_IO.Put_Line( "Starting Task Hello." );
loop
select
accept Stop do
null;
end Stop;
Finished:= True;
OR
delay Cycle_Timing.all;
end select;
Exit when Finished;
-- TIMED PORTION.
Ada.Text_IO.Put_Line( "The time is now: " &
Ada.Calendar.Formatting.Image(
Ada.Calendar.Clock
)
& '.' );
end loop;
Ada.Text_IO.Put_Line( "Finishing Task Hello." );
End Hello;
Greeter : Hello( new Duration'(3.0) ); -- 3 second cycle.
Begin
--Runner;
declare
-- Wait until the user hits enter...
Tmp : String renames Get_Line;
Begin
-- then stop the Greeter task.
Greeter.Stop;
End;
End Test;
^ permalink raw reply [relevance 7%]
* Re: NTP
@ 2017-09-18 8:21 8% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2017-09-18 8:21 UTC (permalink / raw)
On 18/09/2017 09:54, Tarjei Jensen wrote:
> I'd just like to point out to the unwary that the time you get is GMT or UTC.
You mean that Ada.Calendar.Formatting.Time_Of with Time_Zone = 0 returns
GMT and not UTC? And specifically that
Ada.Calendar.Time_Of (...) /=
Ada.Calendar.Formatting.Time_Of (..., Time_Zone => UTC_Time_Offset)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 8%]
* Re: NTP
@ 2017-09-16 9:29 7% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2017-09-16 9:29 UTC (permalink / raw)
On 2017-09-16 08:40, Anatoly Chernyshev wrote:
> Is there a way to get time via the Network Time Protocol in Ada? It
> doesn't look like AWS has it (or I've missed something).
>
> Currently I'm getting around spawning the Cygwin "nc" command, but it hurts my feelings.
Do you mean send a single UDP request to an NTP server and convert the
response to Ada time?
You can try this:
----------------------------------------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Calendar; use Ada.Calendar;
with Ada.Calendar.Formatting; use Ada.Calendar.Formatting;
with Ada.Exceptions; use Ada.Exceptions;
with Ada.Streams; use Ada.Streams;
with GNAT.Sockets; use GNAT.Sockets;
with Interfaces; use Interfaces;
procedure Test is
function Get_NTP_Time
( Server : String;
Timeout : Timeval_Duration := 10.0
) return Time is
NTP_Packet_Size : constant := 48;
-- RFC 5905: Official NTP era begins at 1 Jan 1900. We cannot
-- have it in Ada.Calendar.Time, so taking a later time. Note
-- Time_Zone = 0 in order to have it UTC
Era : constant Time := Time_Of (1999, 12, 31, Time_Zone => 0);
-- RFC 5905: seconds since 1 Jan 1900 to 31 Dec 1999
Era_Offset : constant := 3_155_587_200;
Socket : Socket_Type;
Address : Sock_Addr_Type;
Seconds : Unsigned_32;
Fraction : Unsigned_32;
Last : Stream_Element_Offset;
Data : Stream_Element_Array (1..NTP_Packet_Size) :=
( 1 => 2#1110_0011#, -- LI, Version, Mode
2 => 0, -- Stratum, or type of clock
3 => 0, -- Polling Interval
4 => 16#EC#, -- Peer Clock Precision
13 => 49,
14 => 16#4E#,
15 => 49,
16 => 52,
others => 0
);
begin
Address.Addr := Addresses (Get_Host_By_Name (Server), 1);
Address.Port := 123; -- NTP port
Create_Socket (Socket, Family_Inet, Socket_Datagram);
Set_Socket_Option
( Socket,
Socket_Level,
(Receive_Timeout, Timeout)
);
Send_Socket (Socket, Data, Last, Address);
Receive_Socket (Socket, Data, Last, Address);
if Last /= Data'Last then
Raise_Exception (Data_Error'Identity, "Mangled response");
end if;
Seconds := ( Unsigned_32 (Data (41)) * 2**24
+ Unsigned_32 (Data (42)) * 2**16
+ Unsigned_32 (Data (43)) * 2**8
+ Unsigned_32 (Data (44))
- Era_OFfset
);
Fraction := ( Unsigned_32 (Data (45)) * 2**24
+ Unsigned_32 (Data (46)) * 2**16
+ Unsigned_32 (Data (47)) * 2**8
+ Unsigned_32 (Data (48))
);
return ( Era
+ Duration (Seconds)
-- + Duration (Long_Float (Fraction) / 2.0**32)
);
end Get_NTP_Time;
Stamp : Time;
begin
Stamp := Get_NTP_Time ("time.nist.gov");
Put_Line ("NTP time " & Image (Stamp));
exception
when Error : others =>
Put_Line ("Error: " & Exception_Information (Error));
end Test;
-------------------------------------------------------------------
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: GNATCOLL SQLite3 vs Ada.Calendar.Time
@ 2016-08-18 22:05 5% ` Randy Brukardt
0 siblings, 0 replies; 104+ results
From: Randy Brukardt @ 2016-08-18 22:05 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:np53eg$1o71$1@gioia.aioe.org...
...
> When storing timestamps into SQLite3 it is better to use TEXT and some
> custom time/string conversion that would guarantee proper ordering and
> precision.
For many purposes, the ISO-standard format used by Ada.Calendar.Formatting
is sufficient; the package includes conversions both ways. The ISO format
has a fixed size (so it works well with Ada strings), and it is formatted
such that normal string comparisons give an appropriate ordering.
The only reasons to use a custom format would be if one needed to use a
shorter format for some reason, or if one needs more precision than 1/100
seconds. Otherwise, sticking with the standard format allows using
language-defined routines available on all Ada 2005 and later compilers
(*much* less chance of making a conversion mistake).
Randy.
^ permalink raw reply [relevance 5%]
* Re: ANN: Introducing AdaBase - Thick database bindings for Ada
@ 2016-05-16 20:06 5% ` Randy Brukardt
0 siblings, 0 replies; 104+ results
From: Randy Brukardt @ 2016-05-16 20:06 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]
<gautier_niouzes@hotmail.com> wrote in message
news:f1c76310-e74f-4734-9961-5743e877b5e2@googlegroups.com...
>Le samedi 14 mai 2016 01:37:02 UTC+2, Randy Brukardt a écrit :
>> Impossible, I fear. I tried that with Claw, but even having a several
>> year
>> head start didn't prevent someone from making their own incompatible
>> version.
>
>And in retrospect, it was a good thing: since around 2000, GWindows [1] is
>the only Ada thick binding for Windows maintained, developed, and usable
>for real applications (just tested the 3rd one, JEWL [2]; builds and runs
>fine,
>but very limited beyond demos or toy projects).
Not remotely true (except the point about JEWL - but it was always intended
to be easy rather than powerful).
(1) Plenty of real-world projects use/used Claw - I haven't asked for
permission to talk about customers projects, but we've used it for the
Trash-Finder UI, for the Claw Builder itself (a *very* tough task for an
interface library), and a variety of internal tools.
(2) Claw was actively developed for many years after 2000, and still is
actively maintained now. (Not doing much development because of lack of
demand.)
(3) The above of course is a self-fufilling prophecy; once the split
happened, the community had to make a choice and the effect was to duplicate
all of the effort spent on Claw. The same effort could have been spent on
enhancing Claw and more good stuff would have been available.
At least Claw was not a total waste of time: (1) it toughened up the OOP and
finalization support in Ada compilers, so GWindows and the like were even
possible. (When we started with Claw, most of our code didn't work on early
Ada 95 compilers for one reason or another.) (2) Claw.Directories turned
into Ada.Directories, and Claw.Time turned into Ada.Calendar.Arithmetic and
Ada.Calendar.Formatting - so those things are now available to all Ada
programmers. Too bad that I could never get Ada.Sockets (after Claw.Sockets)
off the ground.
Randy.
^ permalink raw reply [relevance 5%]
* Re: A few questions
2015-10-31 20:49 5% ` Dmitry A. Kazakov
@ 2015-11-02 17:45 7% ` Simon Wright
1 sibling, 0 replies; 104+ results
From: Simon Wright @ 2015-11-02 17:45 UTC (permalink / raw)
Laurent <lutgenl@icloud.com> writes:
> Hi
>
> I need a range of Dates.
I wrote the attached, using generalized iteration, which bears a strong
resemblance to the standard container iteration (the names bear too
strong a resemblance! but this way you can see the commonality).
I'd have liked to support
for D in Period loop
...
but "array type required in indexed component" (which I think means that
Date_Container needs the Constant_Indexing aspect?).
Running this test just now,
with Date_Iteration;
with Ada.Calendar.Formatting;
with Ada.Text_IO; use Ada.Text_IO;
procedure Date_Iteration_Test is
use type Ada.Calendar.Time;
Period : Date_Iteration.Date_Container;
Day : constant Duration := 86_400.0;
begin
Period.Initialize (Start_Time => Ada.Calendar.Clock,
End_Time => Ada.Calendar.Clock + Day * 10,
Interval => Day / 2);
for C in Period.Iterate loop
Put_Line (Ada.Calendar.Formatting.Image (Date_Iteration.Element (C)));
end loop;
end Date_Iteration_Test;
I got
$ ./date_iteration_test
2015-11-02 17:35:03
2015-11-03 05:35:03
2015-11-03 17:35:03
2015-11-04 05:35:03
2015-11-04 17:35:03
2015-11-05 05:35:03
2015-11-05 17:35:03
2015-11-06 05:35:03
2015-11-06 17:35:03
2015-11-07 05:35:03
2015-11-07 17:35:03
2015-11-08 05:35:03
2015-11-08 17:35:03
2015-11-09 05:35:03
2015-11-09 17:35:03
2015-11-10 05:35:03
2015-11-10 17:35:03
2015-11-11 05:35:03
2015-11-11 17:35:03
2015-11-12 05:35:03
2015-11-12 17:35:03
========================================================================
with Ada.Calendar;
with Ada.Iterator_Interfaces;
package Date_Iteration is
type Date_Container is tagged private
with
Default_Iterator => Iterate,
Iterator_Element => Ada.Calendar.Time;
procedure Initialize (D : out Date_Container;
Start_Time : Ada.Calendar.Time;
End_Time : Ada.Calendar.Time;
Interval : Duration := 86_400.0);
type Cursor is private;
No_Element : constant Cursor;
function First (Container : Date_Container) return Cursor;
function Next (Position : Cursor) return Cursor;
function Element (Position : Cursor) return Ada.Calendar.Time;
function Has_Element (C : Cursor) return Boolean;
package Iterator_Interfaces
is new Ada.Iterator_Interfaces (Cursor, Has_Element);
function Iterate (Container : Date_Container)
return Iterator_Interfaces.Forward_Iterator'Class;
private
type Date_Container is tagged record
Start_Time : Ada.Calendar.Time;
End_Time : Ada.Calendar.Time;
Interval : Duration;
end record;
type Date_Container_Access is access all Date_Container;
for Date_Container_Access'Storage_Size use 0;
type Cursor is record
Container : Date_Container_Access;
Index : Ada.Calendar.Time;
end record;
No_Element : constant Cursor
:= (Container => null, Index => Ada.Calendar.Clock);
type Iterator is new Iterator_Interfaces.Forward_Iterator
with record
Container : Date_Container_Access;
end record;
overriding
function First (Object : Iterator) return Cursor;
overriding
function Next (Object : Iterator; Position : Cursor) return Cursor;
end Date_Iteration;
package body Date_Iteration is
procedure Initialize (D : out Date_Container;
Start_Time : Ada.Calendar.Time;
End_Time : Ada.Calendar.Time;
Interval : Duration := 86_400.0) is
begin
D := (Start_Time => Start_Time,
End_Time => End_Time,
Interval => Interval);
end;
function First (Container : Date_Container) return Cursor is
begin
return C : Cursor do
C.Container := Container'Unrestricted_Access;
C.Index := Container.Start_Time;
end return;
end First;
function Next (Position : Cursor) return Cursor is
use type Ada.Calendar.Time;
begin
if Position.Container = null then
return No_Element;
end if;
return C : Cursor do
C.Container := Position.Container;
C.Index := Position.Index + Position.Container.Interval;
end return;
end Next;
function Element (Position : Cursor) return Ada.Calendar.Time is
(Position.Index);
function Has_Element (C : Cursor) return Boolean is
use type Ada.Calendar.Time;
begin
return C.Index <= C.Container.End_Time;
end Has_Element;
function Iterate (Container : Date_Container)
return Iterator_Interfaces.Forward_Iterator'Class is
begin
return It : Iterator do
It.Container := Container'Unrestricted_Access;
end return;
end Iterate;
function First (Object : Iterator) return Cursor is
begin
return Object.Container.First;
end First;
function Next (Object : Iterator; Position : Cursor) return Cursor is
begin
if Position.Container = null then
return No_Element;
end if;
if Position.Container /= Object.Container then
raise Program_Error with "container/cursor mismatch";
end if;
return Next (Position);
end Next;
end Date_Iteration;
^ permalink raw reply [relevance 7%]
* Re: A few questions
2015-10-31 20:49 5% ` Dmitry A. Kazakov
@ 2015-11-01 13:16 0% ` Laurent
0 siblings, 0 replies; 104+ results
From: Laurent @ 2015-11-01 13:16 UTC (permalink / raw)
On Saturday, 31 October 2015 21:49:24 UTC+1, Dmitry A. Kazakov wrote:
> > subtype Period is range Begin_Date .. End_Date;
>
> 1. How is this subtype would be different from Date?
>
Perhaps in some declarative language where lists are an fundamental part of the language itself the compiler could be smart enough to make Period a list and fill it with dates from..to? Yeah I know mind-reading compiler and World of Fantasycraft :)
> 2. Date is not a numeric type to have ranges
Agreed
> 3. Date cannot be a numeric type because arithmetic operations would not
> make sense: D1 + D2 is what?
Nonsense :)
> > I naively thought that it could be so easy.
>
> Yes, because it is wrong.
What? Being naive or thinking that it could/should be easy? :)
> > I have found in Ada.Calendar a: function "-" (L,R:Time) return Duration
>
> Similarly D1 - D2 is a Duration, not a date. Likewise you can add duration
> to a date, but not a date to date.
>
> > Is it possible to make a casting to convert my Date type in (Ada.Calendar) Time type:
> >
> > Today : Ada.Calendar.Time:= Time(Date); -- or something like that.
>
> No problem. You would have an equivalent of Year, Month, Day functions
> defined for Date. Then you would call Time_Of. That is.
I actually mentioned the "-" only because it would spare me from having to roll my own to figure out how many days are between D1 and D2.
But I think that it is probably not necessary at all.
> > So is there an existing package which generates a range of Dates from .. to?
>
> No, but you could have an abstract iterator for dates in Ada 2012.
>
> > PS: need this range of dates because the log files I want to read and
> > extract informations from are all named like this: vba-yyyymmdd.log where
> > obviously yyyymmdd is the date. The program generates a new file every
> > date an stores the communication it treated in it.
>
> See Ada.Calendar.Formatting.Image.
I think getting the names done is the easiest part.
When first took a look at the log files I thought that it would be difficult to extract the informations I am looking for. But no getting some continuous dates from .. to is the real PITA.
Otherwise it would be boring.
Thanks
^ permalink raw reply [relevance 0%]
* Re: A few questions
@ 2015-10-31 20:49 5% ` Dmitry A. Kazakov
2015-11-01 13:16 0% ` Laurent
2015-11-02 17:45 7% ` Simon Wright
1 sibling, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2015-10-31 20:49 UTC (permalink / raw)
On Sat, 31 Oct 2015 13:29:51 -0700 (PDT), Laurent wrote:
> I need a range of Dates.
>
> So I tried this:
>
> Begin_Date: Dates.Object;
> End_Date: Dates.Object;
> -- Dates is a package from an earlier example in my Ada95 book. It is based on Ada.Calendars. I prefer to use
> -- Dates because I actually need only the date, I don't care/ need the hour. I also find the name "Time" for
> -- something like "2015/10/31 21:00:00" confusing but that's just my opinion.
>
> That doesn't work unfortunately and the compiler is right to complain:
>
> subtype Period is range Begin_Date .. End_Date;
1. How is this subtype would be different from Date?
2. Date is not a numeric type to have ranges
3. Date cannot be a numeric type because arithmetic operations would not
make sense: D1 + D2 is what?
> I naively thought that it could be so easy.
Yes, because it is wrong.
> I have found in Ada.Calendar a: function "-" (L,R:Time) return Duration
Similarly D1 - D2 is a Duration, not a date. Likewise you can add duration
to a date, but not a date to date.
> Is it possible to make a casting to convert my Date type in (Ada.Calendar) Time type:
>
> Today : Ada.Calendar.Time:= Time(Date); -- or something like that.
No problem. You would have an equivalent of Year, Month, Day functions
defined for Date. Then you would call Time_Of. That is.
> So is there an existing package which generates a range of Dates from .. to?
No, but you could have an abstract iterator for dates in Ada 2012.
> PS: need this range of dates because the log files I want to read and
> extract informations from are all named like this: vba-yyyymmdd.log where
> obviously yyyymmdd is the date. The program generates a new file every
> date an stores the communication it treated in it.
See Ada.Calendar.Formatting.Image.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 5%]
* Time_Zone-aware Day_of_Week ?
@ 2015-07-13 13:26 7% Natasha Kerensikova
0 siblings, 0 replies; 104+ results
From: Natasha Kerensikova @ 2015-07-13 13:26 UTC (permalink / raw)
Hello,
I was implementing some human time formatting with the help of Ada 2005
standard package Ada.Calendar.Formatting, and realized I have an issue
with the function Day_of_Week with regards to time zone.
Everything else in Ada.Calendar.Formatting seems to support some
user-defined time offset, but not Day_of_Week. Is there a particular
reason for that?
Moreover, the description in the ARM of the function is quite terse:
"Returns the day of the week for Time. This is based on the Year, Month,
and Day values of Time."
However, all of Year, Month and Day functions do have the Time_Zone
argument that Day_of_Week lacks. So which time offset is Day_of_Week
supposed to use?
Prying into GNAT's implementation, it seems to use standard system
timezone, but can it be deduced from the ARM?
Is there a workaround to still get a Day_of_Week result that is
consistent with a user-given time offset?
I'm currently leaning towards using Ada.Calendar.Arithmetic.Difference
with a reference date, at midnight in the request time zone, but that
feels a bit inelegant. Is there a better way of doing it?
Thanks for your help,
Natasha
^ permalink raw reply [relevance 7%]
* Re: Is there an easier way for this?
2015-06-21 19:15 6% ` Niklas Holsti
@ 2015-06-21 19:41 0% ` Laurent
0 siblings, 0 replies; 104+ results
From: Laurent @ 2015-06-21 19:41 UTC (permalink / raw)
On Sunday, 21 June 2015 21:15:30 UTC+2, Niklas Holsti wrote:
> Have you looked at Ada.Calendar.Formatting?
>
> http://www.ada-auth.org/standards/12rm/html/RM-9-6-1.html#I4152
>
> There is an Image function there which shows an Ada.Calendar.Time as
> yyyy-mm-dd hh:mm:ss; you could construct your file name by taking
> suitable substrings.
Yes I have seen this one but I don't know why I didn't follow it further. Tunnel vision I suppose.
Thanks
^ permalink raw reply [relevance 0%]
* Re: Is there an easier way for this?
@ 2015-06-21 19:15 6% ` Niklas Holsti
2015-06-21 19:41 0% ` Laurent
0 siblings, 1 reply; 104+ results
From: Niklas Holsti @ 2015-06-21 19:15 UTC (permalink / raw)
On 15-06-21 21:38 , Laurent wrote:
> Hi
>
> I need a function which generates some specific file names:
>
> VITEK2-BCI_yymmdd_hhmmss_x.txt
>
> where yymmdd is the current date, hhmmss the current time and x the number of txt files. No idea if x
> actually important.
>
> I have tinkered this together but I find it quite horrible. Is there a more elegant way to do it?
>
> function Make_File_Name (How_Many : in Positive) return V_String.Bounded_String is
>
> use V_String;
>
> File_Name : V_String.Bounded_String:= (+"VITEK2-BCI_");
> Temp : V_String.Bounded_String;
>
> Right_Now : Ada.Calendar.Time := Ada.Calendar.Clock;
> Y : Positive := Ada.Calendar.Year (Right_Now) rem 100;
> M : Positive := Ada.Calendar.Month (Right_Now);
> D : Positive := Ada.Calendar.Day (Right_Now);
(rest of code snipped)
Have you looked at Ada.Calendar.Formatting?
http://www.ada-auth.org/standards/12rm/html/RM-9-6-1.html#I4152
There is an Image function there which shows an Ada.Calendar.Time as
yyyy-mm-dd hh:mm:ss; you could construct your file name by taking
suitable substrings.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 6%]
* Re: Leap second support and ARM 9.6.1p89/2
@ 2014-08-07 8:59 6% ` Markus Schöpflin
0 siblings, 0 replies; 104+ results
From: Markus Schöpflin @ 2014-08-07 8:59 UTC (permalink / raw)
Am 07.08.2014 09:35, schrieb Natasha Kerensikova:
> Ok, so would I. So I guess the next step is checking who is the
> implementer, i.e. whether's it's AdaCore's problem or FSF's.
>
> Would someone here with a working installation of GNAT GPL 2014 be kind
> enough to test the function in the OP, and tell me whether it's
> affected?
Can't say about GNAT GPL 2014, but I tested it with GNAT Pro 7.1.2 and a
pre-release version of 7.3.0.
> gnatmake -gnata -gnat05 -f test.adb
gcc -c -gnata -gnat05 test.adb
gnatbind -x test.ali
gnatlink test.ali
gnatlink: warning: executable name "test" may conflict with shell command
> ./test
raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : test.adb:50
> sed -n '50p' test.adb
pragma ASSERT (LEAP_SECOND);
HTH, Markus
PS: Next time, please make sure that you post a full example which compiles,
binds, and links correctly. Your code not only needs a main procedure, it also
needs to with & use ADA.CALENDAR.FORMATTING instead of ADA.CALENDAR.TIME.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 19:07 7% ` Adam Beneschan
@ 2012-07-24 20:17 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2012-07-24 20:17 UTC (permalink / raw)
On Tue, 24 Jul 2012 12:07:52 -0700 (PDT), Adam Beneschan wrote:
> On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote:
>> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
>>
>> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901.
>> > Or, better, if the NTP time is always UTC, then you should probably use
>> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
>> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
>> > Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct me if
>> > I'm supposed to negate the value.)
>>
>> There is no simple way of converting Ada.Calendar.Time to UTC. At least
>> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
>> sort of.
>
> The problem here, I think, is that the concept of "converting
> Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat
> vague. I'm not trying to explain how to work with UTC time in general;
> I'm trying to solve a specific problem.
>
> The specific problem (as I understood it) was this: You have an integer
> value that represents a specific *point* *in* *time* T1 by specifying the
> number of seconds that have elapsed since midnight on New Years Day in
> Greenwich.
T1 [GMT]
> You have another value that was returned by Ada.Calendar.Clock at some
> other point in time T2.
T2 [nobody knows what]
> My contention is that you can create an Ada.Calendar.Time value to
> represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable
> Time_Offset,
The problem is the Time_Offset, where do you get it? You need
GMT_Time_Offset, which firstly is not defined, and secondly if it were
there, it would be no more constant than the UTC_Time_Offset is.
Once you get T1 and T2 to the same time basis of more or less monotonic
time, e.g. GMT, UTC, whatever, but *not* a political time, there will be no
further problems.
> Furthermore, I don't see how Ada.Real_Time is a solution; that package's
> purpose is, I think, to provide a better way to measure time *intervals*
> with a higher resolution, but it doesn't do all that well with absolute
> time (the RM says that Real_Time is considered relative to an undefined
> "epoch" that could be the last system boot time). So I don't see how it
> could be involved in a solution to this particular problem.
Ada.Real_Time.Time is not a full solution. It only provides sane time
arithmetic, e.g. "+", "-". A numeric type could do this as well.
Ada.Calendar.Time cannot give even that little. You could not define
arithmetical operations on it in any reasonable way. This is of course
because of time skews, which make some values non-existent and some values
repeating. I presume that any Ada implementation of it is broken in this or
other way, which is irrelevant here, because there is no way to have
arithmetic on something that is not additive anyway. I posted a couple
examples for CET on the topic to Ada Comments some time ago.
So the rule is: do not do any computations with Ada.Calendar.Time. Ada RM
simply does not define the outcome.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
@ 2012-07-24 16:26 6% ` Adam Beneschan
2012-07-24 18:28 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Adam Beneschan @ 2012-07-24 16:26 UTC (permalink / raw)
On Tuesday, July 24, 2012 12:24:17 AM UTC-7, erlo....@gmail.com wrote:
> NTP epoch 1 started 1-1-1900 0:00, just like the Unix epoch started 1-1-1970
> 0:00. So when I get a time from an NTP-server, I get seconds from the start of
> the NTP epoch.
All right, then. First of all, I don't know what Ada.Calendar.Conversions is. It's not defined by the language, but rather by one particular implementor. IMHO you should prefer to use the language-defined packages if at all feasible. It will be more portable, plus a lot of work goes into making sure things in the Standard have precise definitions.
If you have an integer value N representing the number of seconds since 1/1/1900, I think you want to convert this to an Ada.Calendar.Time that represents the same point in time, so that you can then compare it easily to another value of Ada.Calendar.Time. If Ada had a Time that represented 1/1/1900, you could just take that Time and add N seconds to it. But, as you found out, it didn't, so the first step is to convert N to a value N2 representing the number of seconds since 1/1/1901. You can do this by setting N2 := N - constant (you'd better be able to figure out what the constant is!). As I implied before, if N2 is negative then some very weird stuff is going on, so don't worry about that possibility.
Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901.
Or, better, if the NTP time is always UTC, then you should probably use Ada.Calendar.Formatting.Time_Of to create a time that represents midnight of 1/1/1901 in UTC time; I think you do this by passing Time_Zone => Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct me if I'm supposed to negate the value.)
Now, you *may* be able to create a Time T representing your NTP time just by setting
T := T_Base + Duration(N2);
This will work on some implementations. On other implementations, though, Duration isn't guaranteed to have a range that covers 112 years or more (the language only requires that it covers one day). You can get around this by breaking N2 into "days" and "seconds":
N2_Days := N2 / 86_400;
N2_Seconds := N2 mod 86_400;
T := T_Base + Day_Count (N2_Days) + Duration (N2_Seconds);
The Day_Count type is defined in Ada.Calendar.Arithmetic.
Now T will be a Time value that represents the point in time that occurred N seconds after midnight on 1/1/1900 (UTC), and you can compare this to any other Time value.
-- Adam
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar Question
@ 2012-07-20 18:24 7% ` awdorrin
0 siblings, 0 replies; 104+ results
From: awdorrin @ 2012-07-20 18:24 UTC (permalink / raw)
I finally realized that these nested packages are tagged private. Now it makes sense.
It looks like the 'easiest' way for me to get from the stored 'seconds' and 'nanoseconds' is to do the following:
procedure Example( sec : in Integer; nSec : in Integer) is
T : Ada.Calendar.Time;
begin
T := Ada.Calendar.Conversions.To_Ada_Time(0) -- to get epoch
+ Ada.Calendar.Conversions.To_Duration( long(sec), long(nSec));
Put_Line( Ada.Calendar.Formatting.Image(
Date => T, Include_Time_Fraction => True,
Time_Zone => Ada.Calendar.Time_Zones.UTC_Time_Offset(T) );
end Example;
The 'To_Duration' is a bit annoying, requiring withing the 'Interfaces.C' package for the 'long' type, but it does work fine.
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 16:26 6% ` Adam Beneschan
@ 2012-07-24 18:28 0% ` Dmitry A. Kazakov
2012-07-24 19:07 7% ` Adam Beneschan
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2012-07-24 18:28 UTC (permalink / raw)
On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
> Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901.
> Or, better, if the NTP time is always UTC, then you should probably use
> Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
> of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
> Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct me if
> I'm supposed to negate the value.)
There is no simple way of converting Ada.Calendar.Time to UTC. At least
there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
sort of.
The problem is that UTC_Time_Offset has time argument. It is not constant.
UTC_Time_Offset jumps forth and back together with the political time.
Furthermore, operations like UTC_Time_Offset, Time_Of, Split for some
distant time in the past, e.g. 1901 are most likely wrong, because OS/Ada's
RTL cannot keep track of all political changes of all time zones in order
to be able to evaluate the number of seconds from present time to 1901 in
the time zone. It is *not* the number of years multiplied by the year's
duration. (IANA Time Zone Database or alike is required for that)
Calculating future times is absolutely impossible because that depends on
future decisions of the corresponding governmental bodies having the
authority over the time zone, from daylight saving time to changing the
whole zone.
This is why it is better not to touch Ada.Calendar.Time.
Ada.Real_Time, Duration, Time_Span, some numeric type would be much better
candidates.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 18:28 0% ` Dmitry A. Kazakov
@ 2012-07-24 19:07 7% ` Adam Beneschan
2012-07-24 20:17 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Adam Beneschan @ 2012-07-24 19:07 UTC (permalink / raw)
On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote:
> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
>
> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901.
> > Or, better, if the NTP time is always UTC, then you should probably use
> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
> > Ada.Calendar.Time_Zones.UTC_Time_Offset. (Somebody please correct me if
> > I'm supposed to negate the value.)
>
> There is no simple way of converting Ada.Calendar.Time to UTC. At least
> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
> sort of.
The problem here, I think, is that the concept of "converting Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat vague. I'm not trying to explain how to work with UTC time in general; I'm trying to solve a specific problem.
The specific problem (as I understood it) was this: You have an integer value that represents a specific *point* *in* *time* T1 by specifying the number of seconds that have elapsed since midnight on New Years Day in Greenwich. You have another value that was returned by Ada.Calendar.Clock at some other point in time T2. My contention is that you can create an Ada.Calendar.Time value to represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable Time_Offset, and using the "+" functions defined in Ada.Calendar and Ada.Calendar.Formatting, that produces an Ada.Calendar.Time value representing T1 that can correctly be compared with T2 (and subtracted to produce a Duration).
Do you believe my contention is incorrect? If so, please demonstrate.
It's true, as you say, that UTC_Time_Offset's result isn't constant, and changes when the time zone goes in and out of Daylight Savings Time. The point is, I was trying to use it in a way that would cancel out the effect of that, producing a result in which the "offsets" factored into the two Ada.Calendar.Time values being compared are the same, which means that you can compare or subtract them correctly, regardless of whether the offsets would be different if you ran the program six months from now. I may have done it wrong, but I don't believe it is impossible. If it is, please show why.
There are certainly a lot of things that are difficult to get right with Ada.Calendar for some of the reasons you state. I don't think any of those are relevant to solving *this* particular problem. Furthermore, I don't see how Ada.Real_Time is a solution; that package's purpose is, I think, to provide a better way to measure time *intervals* with a higher resolution, but it doesn't do all that well with absolute time (the RM says that Real_Time is considered relative to an undefined "epoch" that could be the last system boot time). So I don't see how it could be involved in a solution to this particular problem.
-- Adam
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Formatting bug in GNAT?
2011-09-16 19:55 13% Ada.Calendar.Formatting bug in GNAT? Maciej Sobczak
@ 2011-09-17 5:59 7% ` Randy Brukardt
0 siblings, 0 replies; 104+ results
From: Randy Brukardt @ 2011-09-17 5:59 UTC (permalink / raw)
"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:e781c174-04fe-4445-9788-c6f619439c5d@l2g2000vbn.googlegroups.com...
...
> I have an additional question, though: why the constraints of
> Day_Duration were not detected at the point of call to Split, but
> rather later on with explicit test on Seconds'Valid? My understanding
> is that this should be checked at the point of call to Split, so that
> additional checks inside Split should not be necessary. A possible
> explanation is that the library was compiled with checks disabled and
> the explicit test was added to cover up for this, but maybe I'm
> missing something here.
My understanding is that the GNAT runtime is always compiled with checks
turned off, so I presume they write explicit checks whenever they are
needed. (We do something similar for the Janus/Ada runtime.)
As for the original problem, it surely sounds like a bug.
Randy.
^ permalink raw reply [relevance 7%]
* Ada.Calendar.Formatting bug in GNAT?
@ 2011-09-16 19:55 13% Maciej Sobczak
2011-09-17 5:59 7% ` Randy Brukardt
0 siblings, 1 reply; 104+ results
From: Maciej Sobczak @ 2011-09-16 19:55 UTC (permalink / raw)
I have a problem with Ada.Calendar.Formatting.Image with the Duration
parameter.
As far as I understand 9.6.1, points 86.a/2:
"Implementation defined: The result of Calendar.Formating.Image if its
argument represents more than 100 hours."
and 86.b/2:
"Implementation Note: This cannot be implemented (directly) by calling
Calendar.Formatting.Split, since it may be out of the range of
Day_Duration, and thus the number of hours may be out of the range of
Hour_Number."
the Image function should cope with Durations longer than one day (but
not longer than 100 hours) and Day_Duration should not be a limitation
here.
Let's try:
with Ada.Calendar.Formatting;
with Ada.Text_IO;
procedure Test is
Hour : constant Duration := 3_600.0;
D_1 : constant Duration := 23 * Hour;
D_2 : constant Duration := 25 * Hour;
begin
Ada.Text_IO.Put_Line (Ada.Calendar.Formatting.Image (D_1));
Ada.Text_IO.Put_Line (Ada.Calendar.Formatting.Image (D_2));
end Test;
$ ./test
23:00:00
raised CONSTRAINT_ERROR : a-calfor.adb:381 explicit raise
$
The a-calfor.adb:381 is a raise statement in:
if not Seconds'Valid then
raise Constraint_Error;
end if;
where Seconds is of type Day_Duration in function Split. Yes, the same
Split which should not be used according to AARM.
Is this a bug in the GNAT library? I think so.
I have an additional question, though: why the constraints of
Day_Duration were not detected at the point of call to Split, but
rather later on with explicit test on Seconds'Valid? My understanding
is that this should be checked at the point of call to Split, so that
additional checks inside Split should not be necessary. A possible
explanation is that the library was compiled with checks disabled and
the explicit test was added to cover up for this, but maybe I'm
missing something here.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
^ permalink raw reply [relevance 13%]
* Dates and Times in GNAT on Linux
@ 2009-09-13 15:36 6% Marc A. Criley
0 siblings, 0 replies; 104+ results
From: Marc A. Criley @ 2009-09-13 15:36 UTC (permalink / raw)
I'm confused about GNAT's implementation of some aspects of date/time
processing on Linux. I'm running GNAT GPL 2009 on Ubuntu Linux; I also
live in the US Central Time Zone and Daylight Savings Time is in effect
as I write this.
This is probably a stupid misunderstanding or mistaken expectations or
feature misuse on my part, but I would really like to know what's going on.
Basically what I'm trying to do is take the time I got from from
Ada.Real.Clock and convert it to a date/time rep. The result I'm coming
up with is always an hour off. (DST effect? Read on...) Code will follow
in a bit.
I discovered that GNAT's implementation of Ada.Real_Time.Clock returns
the number of seconds since the UTC epoch start, which is very nice and
very handy. Using Real_Time.Split I can get that number of seconds into
a visible type, Seconds_Count.
I can then get the start of the Unix/UTC epoch via:
UTC_Epoch_Start := Calendar.Time_Of(1970, 1, 1)
+ Duration(Calendar.Time_Zones.UTC_Offset * 60);
-- For where I live, right now the UTC_Offset is -300 minutes,
-- i.e. -5 hours.
Adding the Real_Time seconds count (as a Duration) to UTC_Epoch_Start
gives a Calendar.Time value containing the current UTC time, from which
I can generate an image...which is an hour off from the correct value.
So I'm thinking it might be a DST problem, but shouldn't the affected
Calendar procedures be taking that into account?
I saw that the Ada.Calendar package body uses a C function,
__gnat_localtime_tzoff(), which has "Parameter 'off' captur[ing] the UTC
offset which is either retrieved from the tm struct or calculated from
the 'timezone' extern and the tm_isdst flag in the tm struct." Looking
at the code for this function it appears that _for_Linux_ the
implementation ignores the "tm_isdst" value and just uses the
"tm_gmtoff" value, while for some other Unices it does look at tm_isdst.
I'd like to think there's a good reason for doing that--including me
being an idiot--but I don't see what's going on. And unfortunately I
don't yet have a support contract with AdaCore :-)
I hacked together some C and Ada examples to illustrate this:
tmt.c:
#include <time.h>
#include <stdio.h>
void tmt_c_time(time_t rt_secs)
{
struct tm *local;
time_t t;
t = time(NULL);
printf("secs %d\n", t);
local = localtime(&t);
printf("Local time and date: %s\n", asctime(local));
local = gmtime(&t);
printf("UTC time and date: %s\n", asctime(local));
t = rt_secs;
printf("rt secs %d (from Ada)\n", t);
local = localtime(&t);
printf("Local time and date: %s\n", asctime(local));
local = gmtime(&t);
printf("UTC time and date: %s\n", asctime(local));
}
$ gcc -c -g tmt.c
tmtada.adb:
with Text_IO; use Text_IO;
with Ada.Real_Time; use Ada.Real_Time;
with Ada.Calendar.Formatting; use Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones; use Ada.Calendar.Time_Zones;
procedure Tmtada is
T : Time := Clock;
Seconds : Seconds_Count;
Span : Time_Span;
Cal_Time : Ada.Calendar.Time;
UTC_Epoch : Ada.Calendar.Time;
procedure Tmt_C_Time(Rt_Secs : Seconds_Count);
pragma Import(C, Tmt_C_Time, "tmt_c_time");
use Ada.Calendar;
begin
Split(T, Seconds, Span);
Put_Line("Seconds since epoch:" & Seconds'Img);
UTC_Epoch := Ada.Calendar.Time_Of(1970, 1, 1) +
Duration(UTC_Time_Offset * 60);
Cal_Time := UTC_Epoch + Duration(Seconds);
Put_Line("Time Image " & Image(Cal_Time));
New_Line;
Put_Line("Via C...");
Tmt_C_Time(Seconds);
end Tmtada;
$ gnatmake -g tmtada -largs tmt.o
Here's what I get from a run:
[95] Marc say: ./tmtada
Seconds since epoch: 1252855814
Time Image 2009-09-13 16:30:14
Via C...
secs 1252855814
Local time and date: Sun Sep 13 10:30:14 2009
UTC time and date: Sun Sep 13 15:30:14 2009
rt secs 1252855814 (from Ada)
Local time and date: Sun Sep 13 10:30:14 2009
UTC time and date: Sun Sep 13 15:30:14 2009
Maybe my conversion from Real_Time.Time to Calendar.Time is flawed...I
don't know. Any explanation or clarifications would be much appreciated.
Marc A. Criley
Mckae Technologies
www.mckae.com
^ permalink raw reply [relevance 6%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-30 19:44 8% ` reinkor
0 siblings, 0 replies; 104+ results
From: reinkor @ 2009-03-30 19:44 UTC (permalink / raw)
Thanks to all. Now I think I got it !
And giving the argument "Time1" to UTC_Time_Offset" like this:
UTC_Time_Offset(Time1)
insted of only UTC_Time_Offset (which is the same
as "UTC_Time_Offset(Clock))", then I get consistency:
Time1: 1970-01-01 00:00:00
Time2: 1969-12-31 23:00:00
UTC_Time_Offset: 60
Lesson learned: "remember the argument for UTC_Time_Offset" ! :-)
reinert
PS, new program code:
-----------------------------------------------------------------------------
with Text_IO;
use Text_IO;
with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
-- with Ada.Calendar.Aritmetric;
use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
procedure t1 is
package Int_Io is new Text_IO.Integer_Io (Integer);
use Int_Io;
Time1,Time2 : Time;
begin
Time1 := Value("1970-01-01 00:00:00");
Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
Put("Time1: ");Put(Image(Time1));New_Line;
Put("Time2: ");Put(Image(Time2));New_Line;
Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset(Time1)),8);
end t1;
On 30 Mar, 18:52, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
>
> > Put("Time1: ");Put(Image(Time1));New_Line;
> > Put("Time2: ");Put(Image(Time2));New_Line;
>
> > Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
>
> > This gives the following output on my computer:
>
> > Time1: 1970-01-01 00:00:00
> > Time2: 1969-12-31 23:00:00
> > UTC_Time_Offset: 120
>
> > The first line I now understand reflects that both "Value"
> > and "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1"
> > can be understood to have value 1970-01-01 00:00:00 (UTC).
> > "But "Time2" is 1970-01-01 00:00:00 *minus* one hour (only), and
> > UTC_Time_Offset = 120 (2 hours).
>
> I suspect you've recently gone on
> daylight-savings/summer/whatever-it's-called-where-you-are time, which is UTC
> +02:00 (120 mins), but on 1970 Jan 01 you were on regular time, which is UTC +01:00.
>
> --
> Jeff Carter
> "I don't know why I ever come in here. The
> flies get the best of everything."
> Never Give a Sucker an Even Break
> 102
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-30 12:37 7% ` reinkor
@ 2009-03-30 13:45 9% ` John B. Matthews
1 sibling, 0 replies; 104+ results
From: John B. Matthews @ 2009-03-30 13:45 UTC (permalink / raw)
In article
<8aad6593-efb8-441f-9eac-27cf2fe7a124@v38g2000yqb.googlegroups.com>,
reinkor <reinkor@gmail.com> wrote:
> Sorry, I now realized that this was not so intuitive for me.
> Given the following (modified) code:
>
> ------------------------------------------------
> with Text_IO;
> use Text_IO;
>
> with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
> use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
>
> procedure t1 is
>
> package Int_Io is new Text_IO.Integer_Io (Integer);
> use Int_Io;
>
> Time1,Time2 : Time;
>
> begin
>
> Time1 := Value("1970-01-01 00:00:00");
> Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
>
> Put("Time1: ");Put(Image(Time1));New_Line;
> Put("Time2: ");Put(Image(Time2));New_Line;
>
> Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
>
> end t1;
> ------------------------------------
>
> This gives the following output on my computer:
>
> Time1: 1970-01-01 00:00:00
> Time2: 1969-12-31 23:00:00
> UTC_Time_Offset: 120
>
> The first line I now understand reflects that both "Value" and
> "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1" can be
> understood to have value 1970-01-01 00:00:00 (UTC). "But "Time2" is
> 1970-01-01 00:00:00 *minus* one hour (only), and UTC_Time_Offset =
> 120 (2 hours). I would expect that it should be UTC - 2 hours (i.e.
> 1969-12-31 22:00:00 and *not* 1969-12-31 23:00:00) ?
Time1 uses Ada.Calendar.Formatting.Value, with a default Time_Zone of 0.
In contrast, Time2 is the result ofAda.Calendar.Time_Of, which is local
time. I'm guessing you're on Summer (Daylight) time, now; but back on
New Year's day of 1970, you were on standard time.
Here is an example that highlights some of the differences:
with Ada.Calendar; use Ada.Calendar;
with Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones;
use type Ada.Calendar.Time_Zones.Time_Offset;
with Ada.Text_IO; use Ada.Text_IO;
procedure Times is
T : Time := Clock;
D : Time_Zones.Time_Offset;
begin
D := Time_Zones.UTC_Time_Offset(T);
Put("UTC_Time_Offset: "); Put(D'Img); New_Line;
Put("GMT: "); Put(Formatting.Image(T)); New_Line;
Put("Local: "); Put(Formatting.Image(T, False, D)); New_Line;
Put_Line("--");
T := Time_Of(1970, 1, 1, 0.0);
Put(Formatting.Image(T)); New_Line;
Put(Formatting.Image(T, False, -300)); New_Line;
Put_Line("--");
T := Formatting.Time_Of(1970, 1, 1, 0.0);
Put(Formatting.Image(T)); New_Line;
Put(Formatting.Image(T, False, -300)); New_Line;
Put(Formatting.Image(T, False, +60)); New_Line;
end times;
Here's what I see in a New York time zone:
./times
UTC_Time_Offset: -240
GMT: 2009-03-30 13:43:26
Local: 2009-03-30 09:43:26
--
1970-01-01 05:00:00
1970-01-01 00:00:00
--
1970-01-01 00:00:00
1969-12-31 19:00:00
1970-01-01 01:00:00
> I here fight with my intuition :-)
You may want to use the "use" clause a little more sparingly
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
^ permalink raw reply [relevance 9%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
@ 2009-03-30 12:37 7% ` reinkor
2009-03-30 13:45 9% ` John B. Matthews
1 sibling, 2 replies; 104+ results
From: reinkor @ 2009-03-30 12:37 UTC (permalink / raw)
Sorry, I now realized that this was not so intuitive for me.
Given the following (modified) code:
------------------------------------------------
with Text_IO;
use Text_IO;
with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
procedure t1 is
package Int_Io is new Text_IO.Integer_Io (Integer);
use Int_Io;
Time1,Time2 : Time;
begin
Time1 := Value("1970-01-01 00:00:00");
Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
Put("Time1: ");Put(Image(Time1));New_Line;
Put("Time2: ");Put(Image(Time2));New_Line;
Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
end t1;
------------------------------------
This gives the following output on my computer:
Time1: 1970-01-01 00:00:00
Time2: 1969-12-31 23:00:00
UTC_Time_Offset: 120
The first line I now understand reflects that both "Value"
and "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1"
can be understood to have value 1970-01-01 00:00:00 (UTC).
"But "Time2" is 1970-01-01 00:00:00 *minus* one hour (only), and
UTC_Time_Offset = 120 (2 hours).
I would expect that it should be UTC - 2 hours
(i.e. 1969-12-31 22:00:00 and *not* 1969-12-31 23:00:00) ?
I here fight with my intuition :-)
reinert
On 27 Mar, 18:58, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Put(Image(Time1));New_Line;
> > Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> > 1970-01-01 00:00:00
> > 1969-12-31 23:00:00
>
> > The last output line here reflects the fact that Ada takes
> > "local time" from the computer - and the result would be
> > different if I wait to run my program till next Monday
> > (this weekend we change to summer daylight saving time).
>
> No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
> parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
> the supplied time from your computer's offset
> (Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
> offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
> you must specify an offset of UTC_Time_Offset.
>
> The 1st value comes out as expected because Value also takes an
> Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
> (UTC). It is therefore taking the supplied string, interpreting it as a time in
> UTC, and converting it to the corresponding time for your computer's offset
> (UTC_Time_Offset). When you pass this time to Image with the default for
> Time_Zone, the conversion is then reversed as described above.
>
> You can compare the representations provided by Image with the values obtained
> by Ada.Calendar.Split to observe the conversions that the operations in
> Ada.Calendar.Formatting perform.
>
> Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
> Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
> Ada.Calendar.
>
> I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
> shorter.
>
> --
> Jeff Carter
> "My mind is a raging torrent, flooded with rivulets of
> thought, cascading into a waterfall of creative alternatives."
> Blazing Saddles
> 89
^ permalink raw reply [relevance 7%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-27 16:58 8% ` Jeffrey R. Carter
@ 2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 7% ` reinkor
1 sibling, 0 replies; 104+ results
From: reinkor @ 2009-03-30 11:27 UTC (permalink / raw)
Thanks for clarifying.
I thought "Offset" was reletive to UTC - not relative
to the "local" time.
So
Time1 := Value("1970-01-01 00:00:00",Time_Zone => UTC_Time_Offset);
gives UTC for the local "input" time "1970-01-01 00:00:00" ?
How do I best "input"/enter UTC time (so a reader of the program
also understand it - an independent of the computer local time)?
reinert
On 27 Mar, 18:58, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Put(Image(Time1));New_Line;
> > Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> > 1970-01-01 00:00:00
> > 1969-12-31 23:00:00
>
> > The last output line here reflects the fact that Ada takes
> > "local time" from the computer - and the result would be
> > different if I wait to run my program till next Monday
> > (this weekend we change to summer daylight saving time).
>
> No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
> parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
> the supplied time from your computer's offset
> (Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
> offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
> you must specify an offset of UTC_Time_Offset.
>
> The 1st value comes out as expected because Value also takes an
> Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
> (UTC). It is therefore taking the supplied string, interpreting it as a time in
> UTC, and converting it to the corresponding time for your computer's offset
> (UTC_Time_Offset). When you pass this time to Image with the default for
> Time_Zone, the conversion is then reversed as described above.
>
> You can compare the representations provided by Image with the values obtained
> by Ada.Calendar.Split to observe the conversions that the operations in
> Ada.Calendar.Formatting perform.
>
> Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
> Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
> Ada.Calendar.
>
> I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
> shorter.
>
> --
> Jeff Carter
> "My mind is a raging torrent, flooded with rivulets of
> thought, cascading into a waterfall of creative alternatives."
> Blazing Saddles
> 89
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-27 12:52 7% ` reinkor
@ 2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 7% ` reinkor
0 siblings, 2 replies; 104+ results
From: Jeffrey R. Carter @ 2009-03-27 16:58 UTC (permalink / raw)
reinkor wrote:
> Time1 := Value("1970-01-01 00:00:00");
> Put(Image(Time1));New_Line;
> Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> 1970-01-01 00:00:00
> 1969-12-31 23:00:00
>
> The last output line here reflects the fact that Ada takes
> "local time" from the computer - and the result would be
> different if I wait to run my program till next Monday
> (this weekend we change to summer daylight saving time).
No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
the supplied time from your computer's offset
(Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
you must specify an offset of UTC_Time_Offset.
The 1st value comes out as expected because Value also takes an
Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
(UTC). It is therefore taking the supplied string, interpreting it as a time in
UTC, and converting it to the corresponding time for your computer's offset
(UTC_Time_Offset). When you pass this time to Image with the default for
Time_Zone, the conversion is then reversed as described above.
You can compare the representations provided by Image with the values obtained
by Ada.Calendar.Split to observe the conversions that the operations in
Ada.Calendar.Formatting perform.
Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
Ada.Calendar.
I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
shorter.
--
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-27 12:52 7% ` reinkor
2009-03-27 16:58 8% ` Jeffrey R. Carter
0 siblings, 1 reply; 104+ results
From: reinkor @ 2009-03-27 12:52 UTC (permalink / raw)
Given the following Ada code:
with Text_IO,Ada.Calendar,Ada.Calendar.Formatting;
use Text_IO,Ada.Calendar,Ada.Calendar.Formatting;
procedure t1 is
package Int_Io is new Text_IO.Integer_Io (Integer);
use Int_Io;
Time1 : Time;
begin
Time1 := Value("1970-01-01 00:00:00");
Put(Image(Time1));New_Line;
Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
end t1;
This gives (on my linux computer):
1970-01-01 00:00:00
1969-12-31 23:00:00
The last output line here reflects the fact that Ada takes
"local time" from the computer - and the result would be
different if I wait to run my program till next Monday
(this weekend we change to summer daylight saving time).
I would expect that time zones should be explicite - and this would
help programmers to avoid misstakes (which is an argument for Ada).
I made and error due to this my confusion - am I just to much of a
newbie ?
reinert
^ permalink raw reply [relevance 7%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 10:55 0% ` reinkor
@ 2009-03-24 12:49 0% ` Martin
0 siblings, 0 replies; 104+ results
From: Martin @ 2009-03-24 12:49 UTC (permalink / raw)
On 24 Mar, 10:55, reinkor <rein...@gmail.com> wrote:
> On 24 Mar, 11:07, Martin <martin.do...@btopenworld.com> wrote:
>
>
>
>
>
>
>
> > On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
>
> > > What is the "natural"/best way to make an Ada program
> > > treat time/calendar data in UTC ? The quetion is about
> > > treating old measurements/data tagged with UTC time.
>
> > > I use
>
> > > Offset : Constant Time_Offset := UTC_Time_Offset;
>
> > > and include "Time_Zone=>Offset" in calendar routines
> > > (for example in the functions Time_Of, Split, Value
> > > within the packages Ada.Calendar.Formatting and
> > > Ada.Calendar.Time_Zones).
>
> > > I find this a but "artificial". How should one do it?
>
> > > reinert
>
> > Dmitry raises some issue which I'm sure the ARG are looking at but you
> > _might_ be perfectly ok if all you're doing reading log files, etc and
> > not actually trying to combine this with a clock your program is
> > reading and expecting them to tie together with the time on your wrist
> > watch. And if your log didn't come from a run over summer-time
> > changes, leap seconds etc on an OS that actually dealt with such
> > things.
>
> > Cheers
> > -- Martin
>
> So you say that if I make sure nobody runs my program code
> on an advanced computer over summer-time changes, leap seconds etc
> - my program may go correct ?
Without know what you're doing it's hard to say. If you're just using
UTC as a timetag then absolutely you should be ok.
The problems are when the 'real world' goes and changes what 'time' is
- e.g. clocks going forward and backwards, inserting leap seconds.
These sort of things make sensible time computations hard, e.g. what
does "1:30am" mean if the clocks have gone back an hour for winter at
2am? Is it the first 1:30am or the second that night? (can't remember
if it 2am->1am or 3am->2am or something else but you get the idea).
Also leap seconds are interested into OS tables 'retrospectively' - if
you are interested in the difference between to time and need seconds
or better accuracy you again could be in trouble. Do you know your OS
accounts for leap-seconds? If so, do you know if the leap seconds
table is up-to-date?
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 10:07 0% ` Martin
@ 2009-03-24 10:55 0% ` reinkor
2009-03-24 12:49 0% ` Martin
0 siblings, 1 reply; 104+ results
From: reinkor @ 2009-03-24 10:55 UTC (permalink / raw)
On 24 Mar, 11:07, Martin <martin.do...@btopenworld.com> wrote:
> On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
>
>
>
>
>
> > What is the "natural"/best way to make an Ada program
> > treat time/calendar data in UTC ? The quetion is about
> > treating old measurements/data tagged with UTC time.
>
> > I use
>
> > Offset : Constant Time_Offset := UTC_Time_Offset;
>
> > and include "Time_Zone=>Offset" in calendar routines
> > (for example in the functions Time_Of, Split, Value
> > within the packages Ada.Calendar.Formatting and
> > Ada.Calendar.Time_Zones).
>
> > I find this a but "artificial". How should one do it?
>
> > reinert
>
> Dmitry raises some issue which I'm sure the ARG are looking at but you
> _might_ be perfectly ok if all you're doing reading log files, etc and
> not actually trying to combine this with a clock your program is
> reading and expecting them to tie together with the time on your wrist
> watch. And if your log didn't come from a run over summer-time
> changes, leap seconds etc on an OS that actually dealt with such
> things.
>
> Cheers
> -- Martin
So you say that if I make sure nobody runs my program code
on an advanced computer over summer-time changes, leap seconds etc
- my program may go correct ?
reinert
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
@ 2009-03-24 10:07 0% ` Martin
2009-03-24 10:55 0% ` reinkor
1 sibling, 1 reply; 104+ results
From: Martin @ 2009-03-24 10:07 UTC (permalink / raw)
On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
> What is the "natural"/best way to make an Ada program
> treat time/calendar data in UTC ? The quetion is about
> treating old measurements/data tagged with UTC time.
>
> I use
>
> Offset : Constant Time_Offset := UTC_Time_Offset;
>
> and include "Time_Zone=>Offset" in calendar routines
> (for example in the functions Time_Of, Split, Value
> within the packages Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones).
>
> I find this a but "artificial". How should one do it?
>
> reinert
Dmitry raises some issue which I'm sure the ARG are looking at but you
_might_ be perfectly ok if all you're doing reading log files, etc and
not actually trying to combine this with a clock your program is
reading and expecting them to tie together with the time on your wrist
watch. And if your log didn't come from a run over summer-time
changes, leap seconds etc on an OS that actually dealt with such
things.
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
@ 2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
1 sibling, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2009-03-24 9:18 UTC (permalink / raw)
On Tue, 24 Mar 2009 01:51:57 -0700 (PDT), reinkor wrote:
> What is the "natural"/best way to make an Ada program
> treat time/calendar data in UTC ? The quetion is about
> treating old measurements/data tagged with UTC time.
>
> I use
>
> � Offset : Constant Time_Offset := UTC_Time_Offset;
>
> and include "Time_Zone=>Offset" in calendar routines
> (for example in the functions Time_Of, Split, Value
> within �the packages Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones).
>
> I find this a but "artificial". How should one do it?
Sorry for bringing you bad news, but unfortunately there is no way to
handle UTC in Ada. The standard is broken in this respect. I discussed this
in this group earlier and in Ada-Comment too.
The short answer is that if you wanted to deal with UTC, you should have a
look at the implementation of Ada.Calendar.Time provided by your compiler
and then act accordingly.
A longer answer is that UTC_Time_Offset is not necessarily constant. Thus
your way is possibly wrong. Here we come to the inconsistency of the
standard. How does UTC_Time_Offset depend on Time in its turn depends on
what is *Time*. Your solution presumes that Time is UTC (i.e. UTC +
constant offset). This might be wrong, because the standard gives strong
indications that Time is in fact local time = political time. In this case
the offset would depend on the current UTC, and could not depend on Time as
the function UTC_Time_Offset pretends. Offset is not a function of
political time (it is not a function at all). In short, it is broken.
I cannot tell for sure, but it seems that GNAT implementation is Time =
UTC. I.e. Clock does not jump when daylight saving time comes and thus
Split may yield rubbish...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-24 8:51 7% reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
0 siblings, 2 replies; 104+ results
From: reinkor @ 2009-03-24 8:51 UTC (permalink / raw)
What is the "natural"/best way to make an Ada program
treat time/calendar data in UTC ? The quetion is about
treating old measurements/data tagged with UTC time.
I use
Offset : Constant Time_Offset := UTC_Time_Offset;
and include "Time_Zone=>Offset" in calendar routines
(for example in the functions Time_Of, Split, Value
within the packages Ada.Calendar.Formatting and
Ada.Calendar.Time_Zones).
I find this a but "artificial". How should one do it?
reinert
^ permalink raw reply [relevance 7%]
* Re: Performance of element access in Vector
@ 2009-01-23 17:30 8% ` Georg Bauhaus
0 siblings, 0 replies; 104+ results
From: Georg Bauhaus @ 2009-01-23 17:30 UTC (permalink / raw)
Alex R. Mosteo schrieb:
> Georg Bauhaus wrote:
>
>> Maciej Sobczak schrieb:
>>
>>> The problem here is that the compiler does not inline Update_Element/
>>> Query_Element callbacks. Safety and performance are not in conflict
>>> here, it is just a quality of implementation issue.
>>> You can have both.
>> FWIW, if Iterate/Process is made a generic procedure as
>> in the original AI-302, and Increment is made a library
>> level procedure, then GNAT confirms, in a sense,
>> that there might be a quality of implementation issue:
>>
>> raw array : 00:00:29.78
>> raw array process : 00:01:06.74
>> raw array generic : 00:00:29.78
>
> Do you mean, IIUC, that if 'process' where properly inlined, the timing
> would be same for the three instances? That would be nice.
The third line seems to indicate the possibility
of inlining, provided nothing else gets in the
way---in the case of 'Access to procedure; can't say.
Complete example with Increment made a library level
procedure for all three methods:
-- 8<--
procedure Increment (I : in out Integer);
pragma Inline(Increment);
with Ada.Calendar.Formatting;
with Ada.Text_IO;
with Increment;
procedure Test_P is
Iterations: constant := 10_000;
type Int_Array is array(Positive range <>) of Integer;
Start : Ada.Calendar.Time;
Stop : Ada.Calendar.Time;
use type Ada.Calendar.Time;
procedure Test_0A (Container: in out Int_Array;
Process: not null access procedure (Element: in
out Integer)) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for Index in Container'Range loop
Process(Container(Index));
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array process : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0A;
generic
with procedure Process (Element: in out Integer);
procedure Test_0B (Container: in out Int_Array);
procedure Test_0B (Container: in out Int_Array) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for Index in Container'Range loop
Process(Container(Index));
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array generic : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0B;
procedure Test_0(Container: in out Int_Array) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for I in Container'range loop
Container(I) := Container(I) + 1;
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0;
Z: Int_Array(Positive range 1 .. 1_000_000);
begin
Test_0(Z);
Test_0A(Z, Increment'Access);
declare
procedure Test_G is new Test_0B(Process => Increment);
begin
Test_G(Z);
end;
end Test_P;
procedure Increment (I : in out Integer) is
begin
I := I + 1;
end Increment;
^ permalink raw reply [relevance 8%]
* Re: Performance of element access in Vector
@ 2009-01-21 18:08 6% ` Georg Bauhaus
0 siblings, 1 reply; 104+ results
From: Georg Bauhaus @ 2009-01-21 18:08 UTC (permalink / raw)
Maciej Sobczak schrieb:
> The problem here is that the compiler does not inline Update_Element/
> Query_Element callbacks. Safety and performance are not in conflict
> here, it is just a quality of implementation issue.
> You can have both.
FWIW, if Iterate/Process is made a generic procedure as
in the original AI-302, and Increment is made a library
level procedure, then GNAT confirms, in a sense,
that there might be a quality of implementation issue:
raw array : 00:00:29.78
raw array process : 00:01:06.74
raw array generic : 00:00:29.78
with Increment;
...
generic
with procedure Process (Element: in out Integer);
procedure Test_0B (Container: in out Int_Array);
procedure Test_0B (Container: in out Int_Array) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for Index in Container'Range loop
Process(Container(Index));
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array generic : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0B;
declare
procedure Test_G is new Test_0B(Process => Increment);
begin
Test_G(Z);
end;
^ permalink raw reply [relevance 6%]
* Re: Performance of element access in Vector
2009-01-19 3:23 6% ` george.priv
@ 2009-01-19 11:25 8% ` Georg Bauhaus
0 siblings, 0 replies; 104+ results
From: Georg Bauhaus @ 2009-01-19 11:25 UTC (permalink / raw)
george.priv@gmail.com schrieb:
> On Jan 18, 4:42 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>> In a nearby thread I have asked about the performance of
>> Update_Element in Vector.
>> Each of the tests increments all vectors elements, using several
>> element access methods.
>> Just to stir the discussion a bit, a straightforward implementation of
>> the same test in C++ (with the same base compiler and a single -O2
>> option) runs in 13s with indexed access and in 9.5s with iterators -
>> both are based on the use of references, which do not exist in Ada.
>> Not very easy to neglect this difference.
>>
>> All comments are welcome.
> Very interesting.
>
> It seems that compiler is unable to inline. I've added extra test to
> see what will be performance with raw array:
Starting from your test I have added a fake loop.
It is made to simulate the indirection typical of
Vector access, calling Increment via 'Access .
Indeed, inlining does not seem to happen.
Is this a GNAT feature?
gnatmake -O1 -W -g -gnato test_p.adb
raw array : 00:00:57.47
raw array process : 00:02:13.70
gnatmake -s -O2 -gnatn -gnatN -W -gnatp test_p.adb
raw array : 00:00:29.42
raw array process : 00:01:04.18
with Ada.Calendar.Formatting;
with Ada.Text_IO;
procedure Test_P is
Iterations: constant := 10_000;
procedure Increment (I : in out Integer) is
begin
I := I + 1;
end Increment;
type Int_Array is array(Positive range <>) of Integer;
Start : Ada.Calendar.Time;
Stop : Ada.Calendar.Time;
use type Ada.Calendar.Time;
procedure Test_0A (Container: in out Int_Array;
Process: not null access procedure (Element: in out Integer)) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for Index in Container'Range loop
Process(Container(Index));
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array process : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0A;
procedure Test_0(Container: in out Int_Array) is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for I in Container'range loop
Container(I) := Container(I) + 1;
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0;
Z: Int_Array(Positive range 1 .. 1_000_000);
begin
Test_0(Z);
Test_0A(Z, Increment'Access);
end Test_P;
^ permalink raw reply [relevance 8%]
* Re: Performance of element access in Vector
2009-01-18 21:42 8% Performance of element access in Vector Maciej Sobczak
2009-01-19 0:03 0% ` george.priv
@ 2009-01-19 3:23 6% ` george.priv
2009-01-19 11:25 8% ` Georg Bauhaus
2 siblings, 1 reply; 104+ results
From: george.priv @ 2009-01-19 3:23 UTC (permalink / raw)
On Jan 18, 4:42 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> In a nearby thread I have asked about the performance of
> Update_Element in Vector.
> The question was related to using the same interface in smart pointers
> (and other containers/handlers).
>
> So I wrote a test:
>
> with Ada.Calendar.Formatting;
> with Ada.Containers.Vectors;
> with Ada.Text_IO;
>
> procedure A is
>
> package Int_Vectors is new Ada.Containers.Vectors
> (Index_Type => Positive, Element_Type => Integer);
>
> V : Int_Vectors.Vector := Int_Vectors.To_Vector(0, 1_000_000);
>
> procedure Increment (I : in out Integer) is
> begin
> I := I + 1;
> end Increment;
>
> Iterations : constant := 10_000;
>
> Start : Ada.Calendar.Time;
> Stop : Ada.Calendar.Time;
>
> use type Ada.Calendar.Time;
>
> procedure Test_1 is
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> for I in V.First_Index .. V.Last_Index loop
> V.Replace_Element (I, V.Element (I) + 1);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("direct index : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_1;
>
> procedure Test_2 is
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> for I in V.First_Index .. V.Last_Index loop
> V.Update_Element (I, Increment'Access);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Update_Element and index : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_2;
>
> procedure Test_3 is
> C : Int_Vectors.Cursor;
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> C := V.First;
> while Int_Vectors.Has_Element (C) loop
> V.Replace_Element (C, Int_Vectors.Element (C) + 1);
> Int_Vectors.Next (C);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("direct cursor : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_3;
>
> procedure Test_4 is
> C : Int_Vectors.Cursor;
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> C := V.First;
> while Int_Vectors.Has_Element (C) loop
> V.Update_Element (C, Increment'Access);
> Int_Vectors.Next (C);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Update_Element and cursor: " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_4;
>
> procedure Test_5 is
>
> procedure Increment (C : in Int_Vectors.Cursor) is
> begin
> V.Replace_Element (C, Int_Vectors.Element (C) + 1);
> end Increment;
>
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> V.Iterate (Increment'Access);
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Iterate : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_5;
>
> begin
> Test_1;
> Test_2;
> Test_3;
> Test_4;
> Test_5;
> end A;
>
> Each of the tests increments all vectors elements, using several
> element access methods.
> Here we go:
>
> ~/temp/ada $ gnatmake -O2 -gnatn -gnatN a
> gcc -c -O2 -gnatn -gnatN a.adb
> gnatbind -x a.ali
> gnatlink a.ali
> ~/temp/ada $ ./a
> direct index : 00:00:23.34
> Update_Element and index : 00:02:17.20
> direct cursor : 00:01:03.32
> Update_Element and cursor: 00:02:25.82
> Iterate : 00:01:48.67
> ~/temp/ada $
>
> The test shows that Update_Element is several time slower than
> accessing elements by index. Cursor also adds some overhead.
>
> A possible conclusion is that for small elements (simple numeric
> types, etc.) it makes sense to access elements by index, when they are
> copied from and into the container. For larger elements the benefit of
> accessing element in-place can be greater than the overhead of
> Update_Element.
>
> Just to stir the discussion a bit, a straightforward implementation of
> the same test in C++ (with the same base compiler and a single -O2
> option) runs in 13s with indexed access and in 9.5s with iterators -
> both are based on the use of references, which do not exist in Ada.
> Not very easy to neglect this difference.
>
> All comments are welcome.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com
>
> Database Access Library for Ada:www.inspirel.com/soci-ada
Very interesting.
It seems that compiler is unable to inline. I've added extra test to
see what will be performance with raw array:
Z : array (0 .. 1_000_000) of Integer := (others => 0);
procedure Test_0 is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for I in Z'range loop
Z(I) := Z(I) + 1;
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("raw array : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_0;
Results came as:
raw array : 00:00:09.82
direct index : 00:00:23.02
Update_Element and index : 00:01:29.96
direct cursor : 00:02:22.65
Update_Element and cursor: 00:03:36.51
Iterate : 00:02:13.03
^ permalink raw reply [relevance 6%]
* Re: Performance of element access in Vector
2009-01-18 21:42 8% Performance of element access in Vector Maciej Sobczak
@ 2009-01-19 0:03 0% ` george.priv
2009-01-19 3:23 6% ` george.priv
2 siblings, 0 replies; 104+ results
From: george.priv @ 2009-01-19 0:03 UTC (permalink / raw)
On Jan 18, 4:42 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> In a nearby thread I have asked about the performance of
> Update_Element in Vector.
> The question was related to using the same interface in smart pointers
> (and other containers/handlers).
>
> So I wrote a test:
>
> with Ada.Calendar.Formatting;
> with Ada.Containers.Vectors;
> with Ada.Text_IO;
>
> procedure A is
>
> package Int_Vectors is new Ada.Containers.Vectors
> (Index_Type => Positive, Element_Type => Integer);
>
> V : Int_Vectors.Vector := Int_Vectors.To_Vector(0, 1_000_000);
>
> procedure Increment (I : in out Integer) is
> begin
> I := I + 1;
> end Increment;
>
> Iterations : constant := 10_000;
>
> Start : Ada.Calendar.Time;
> Stop : Ada.Calendar.Time;
>
> use type Ada.Calendar.Time;
>
> procedure Test_1 is
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> for I in V.First_Index .. V.Last_Index loop
> V.Replace_Element (I, V.Element (I) + 1);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("direct index : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_1;
>
> procedure Test_2 is
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> for I in V.First_Index .. V.Last_Index loop
> V.Update_Element (I, Increment'Access);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Update_Element and index : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_2;
>
> procedure Test_3 is
> C : Int_Vectors.Cursor;
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> C := V.First;
> while Int_Vectors.Has_Element (C) loop
> V.Replace_Element (C, Int_Vectors.Element (C) + 1);
> Int_Vectors.Next (C);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("direct cursor : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_3;
>
> procedure Test_4 is
> C : Int_Vectors.Cursor;
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> C := V.First;
> while Int_Vectors.Has_Element (C) loop
> V.Update_Element (C, Increment'Access);
> Int_Vectors.Next (C);
> end loop;
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Update_Element and cursor: " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_4;
>
> procedure Test_5 is
>
> procedure Increment (C : in Int_Vectors.Cursor) is
> begin
> V.Replace_Element (C, Int_Vectors.Element (C) + 1);
> end Increment;
>
> begin
> Start := Ada.Calendar.Clock;
>
> for J in 1 .. Iterations loop
> V.Iterate (Increment'Access);
> end loop;
>
> Stop := Ada.Calendar.Clock;
> Ada.Text_IO.Put_Line
> ("Iterate : " &
> Ada.Calendar.Formatting.Image (Stop - Start, True));
> end Test_5;
>
> begin
> Test_1;
> Test_2;
> Test_3;
> Test_4;
> Test_5;
> end A;
>
> Each of the tests increments all vectors elements, using several
> element access methods.
> Here we go:
>
> ~/temp/ada $ gnatmake -O2 -gnatn -gnatN a
> gcc -c -O2 -gnatn -gnatN a.adb
> gnatbind -x a.ali
> gnatlink a.ali
> ~/temp/ada $ ./a
> direct index : 00:00:23.34
> Update_Element and index : 00:02:17.20
> direct cursor : 00:01:03.32
> Update_Element and cursor: 00:02:25.82
> Iterate : 00:01:48.67
> ~/temp/ada $
>
> The test shows that Update_Element is several time slower than
> accessing elements by index. Cursor also adds some overhead.
>
> A possible conclusion is that for small elements (simple numeric
> types, etc.) it makes sense to access elements by index, when they are
> copied from and into the container. For larger elements the benefit of
> accessing element in-place can be greater than the overhead of
> Update_Element.
>
> Just to stir the discussion a bit, a straightforward implementation of
> the same test in C++ (with the same base compiler and a single -O2
> option) runs in 13s with indexed access and in 9.5s with iterators -
> both are based on the use of references, which do not exist in Ada.
> Not very easy to neglect this difference.
>
> All comments are welcome.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com
>
> Database Access Library for Ada:www.inspirel.com/soci-ada
^ permalink raw reply [relevance 0%]
* Performance of element access in Vector
@ 2009-01-18 21:42 8% Maciej Sobczak
2009-01-19 0:03 0% ` george.priv
` (2 more replies)
0 siblings, 3 replies; 104+ results
From: Maciej Sobczak @ 2009-01-18 21:42 UTC (permalink / raw)
In a nearby thread I have asked about the performance of
Update_Element in Vector.
The question was related to using the same interface in smart pointers
(and other containers/handlers).
So I wrote a test:
with Ada.Calendar.Formatting;
with Ada.Containers.Vectors;
with Ada.Text_IO;
procedure A is
package Int_Vectors is new Ada.Containers.Vectors
(Index_Type => Positive, Element_Type => Integer);
V : Int_Vectors.Vector := Int_Vectors.To_Vector(0, 1_000_000);
procedure Increment (I : in out Integer) is
begin
I := I + 1;
end Increment;
Iterations : constant := 10_000;
Start : Ada.Calendar.Time;
Stop : Ada.Calendar.Time;
use type Ada.Calendar.Time;
procedure Test_1 is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for I in V.First_Index .. V.Last_Index loop
V.Replace_Element (I, V.Element (I) + 1);
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("direct index : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_1;
procedure Test_2 is
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
for I in V.First_Index .. V.Last_Index loop
V.Update_Element (I, Increment'Access);
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("Update_Element and index : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_2;
procedure Test_3 is
C : Int_Vectors.Cursor;
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
C := V.First;
while Int_Vectors.Has_Element (C) loop
V.Replace_Element (C, Int_Vectors.Element (C) + 1);
Int_Vectors.Next (C);
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("direct cursor : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_3;
procedure Test_4 is
C : Int_Vectors.Cursor;
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
C := V.First;
while Int_Vectors.Has_Element (C) loop
V.Update_Element (C, Increment'Access);
Int_Vectors.Next (C);
end loop;
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("Update_Element and cursor: " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_4;
procedure Test_5 is
procedure Increment (C : in Int_Vectors.Cursor) is
begin
V.Replace_Element (C, Int_Vectors.Element (C) + 1);
end Increment;
begin
Start := Ada.Calendar.Clock;
for J in 1 .. Iterations loop
V.Iterate (Increment'Access);
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("Iterate : " &
Ada.Calendar.Formatting.Image (Stop - Start, True));
end Test_5;
begin
Test_1;
Test_2;
Test_3;
Test_4;
Test_5;
end A;
Each of the tests increments all vectors elements, using several
element access methods.
Here we go:
~/temp/ada $ gnatmake -O2 -gnatn -gnatN a
gcc -c -O2 -gnatn -gnatN a.adb
gnatbind -x a.ali
gnatlink a.ali
~/temp/ada $ ./a
direct index : 00:00:23.34
Update_Element and index : 00:02:17.20
direct cursor : 00:01:03.32
Update_Element and cursor: 00:02:25.82
Iterate : 00:01:48.67
~/temp/ada $
The test shows that Update_Element is several time slower than
accessing elements by index. Cursor also adds some overhead.
A possible conclusion is that for small elements (simple numeric
types, etc.) it makes sense to access elements by index, when they are
copied from and into the container. For larger elements the benefit of
accessing element in-place can be greater than the overhead of
Update_Element.
Just to stir the discussion a bit, a straightforward implementation of
the same test in C++ (with the same base compiler and a single -O2
option) runs in 13s with indexed access and in 9.5s with iterators -
both are based on the use of references, which do not exist in Ada.
Not very easy to neglect this difference.
All comments are welcome.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Database Access Library for Ada: www.inspirel.com/soci-ada
^ permalink raw reply [relevance 8%]
* Re: Inspiration for a better calendar package?
2008-12-15 12:14 0% ` m.collado
@ 2008-12-15 13:35 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2008-12-15 13:35 UTC (permalink / raw)
On Mon, 15 Dec 2008 13:14:48 +0100, m.collado@domain.invalid wrote:
> Dmitry A. Kazakov escribi�:
>> On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
>>
>>> Additionally we should have time zone tables (without leap second
>>> information) for political time (also needing the ability to
>>> specify "unknown") to do conversions between "political text
>>> representations of time" and "wall clock" time. It also contains
>>> the completely predefined time zone "UTC".
>>
>> I think it can be done much simpler. Conversion to/from political time
>> should simply take time zone offset as the parameter. This is how presently
>> Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
>> has all tables behind the function UTC_Time_Offset. The only problem is the
>> argument of the function. It must be UTC time instead of political one.
>
> Things are in fact more complex than that. The "official" or "political"
> time changes not only with the country, but also with the season,
> because of daylight savings. And the summer/winter periods change over
> years for the same country. So we need a complete history record of
> starting/ending daylight savings periods for each year and each country
> to correctly compute "political" times from UTC times. And the timezone,
> or even the calendar of a given country also changes over years.
>
> As an example of the troubles introduced by a ill-designed time
> reporting policy, consider the way modern MS-Windows OSs report file
> timestamps. They suddently change at the last sunday of March and
> October in european countries. I once had a Modula-2 compiler system
> that unexpectedly ceased to work (reporting broken installation) after
> the first winter/summer change when I activated the "Automatic change
> time with winter/summer time".
Exactly. That is why Ada.Calendar.Time_Zones has to be an optional package
when dealing with time. Presently in order to obtain UTC, we need
Time_Zones (assuming that it weren't broken). That is the world turned
upside down.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inspiration for a better calendar package?
2008-12-15 9:00 5% ` Dmitry A. Kazakov
@ 2008-12-15 12:14 0% ` m.collado
2008-12-15 13:35 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: m.collado @ 2008-12-15 12:14 UTC (permalink / raw)
Dmitry A. Kazakov escribi�:
> On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
>
>> Dmitry A. Kazakov wrote:
>>
>>> We just do not need political time otherwise than for
>>> formatted text output. ...
Agreed.
>>...
>> Additionally we should have time zone tables (without leap second
>> information) for political time (also needing the ability to
>> specify "unknown") to do conversions between "political text
>> representations of time" and "wall clock" time. It also contains
>> the completely predefined time zone "UTC".
>
> I think it can be done much simpler. Conversion to/from political time
> should simply take time zone offset as the parameter. This is how presently
> Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
> has all tables behind the function UTC_Time_Offset. The only problem is the
> argument of the function. It must be UTC time instead of political one.
Things are in fact more complex than that. The "official" or "political"
time changes not only with the country, but also with the season,
because of daylight savings. And the summer/winter periods change over
years for the same country. So we need a complete history record of
starting/ending daylight savings periods for each year and each country
to correctly compute "political" times from UTC times. And the timezone,
or even the calendar of a given country also changes over years.
As an example of the troubles introduced by a ill-designed time
reporting policy, consider the way modern MS-Windows OSs report file
timestamps. They suddently change at the last sunday of March and
October in european countries. I once had a Modula-2 compiler system
that unexpectedly ceased to work (reporting broken installation) after
the first winter/summer change when I activated the "Automatic change
time with winter/summer time".
Regards.
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado
^ permalink raw reply [relevance 0%]
* Re: Inspiration for a better calendar package?
@ 2008-12-15 9:00 5% ` Dmitry A. Kazakov
2008-12-15 12:14 0% ` m.collado
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2008-12-15 9:00 UTC (permalink / raw)
On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
> Dmitry A. Kazakov wrote:
>
>> We just do not need political time otherwise than for
>> formatted text output. It was silly for Ada 2005 to define time
>> arithmetic in terms of political time. Especially because there
>> �simply is no way to define such arithmetic. Since political
>> time increment "+" is not a function of its arguments!
>
> I'd propose using two kinds of time each with an own
> arithmetic -- both of them being not political.
>
> The first one is a somehow physical time, which just counts every
> second occuring in reality. The arithmetic for this one is
> obvious and it should have a fine granularity.
This is Ada.Real_Time.Time. The problem with it is that it does not have
any bias to UTC.
> The second one is a wall clock time with the smallest unit being
> a minute on the wall clock (thus having 59, 60 or 61 seconds
> length). We can define an arithmetic here and it is used to
> specify times related to human activities. This time is used to
> store dates like "second monday after easter 2014 at 10:00 UTC"
> or "every day at 12:00 UTC".
Why cannot you use UTC instead? Political time is a combination of UTC time
and the time zone. The latter is a function that yields the time offset for
each given UTC time value. Yes you could skew the resolution down to the
point where any differences become invisible. What about one year? (:-))
The question what this thing could be used for?
It is a madness to make hour a function of current time and place...
> They should not allow mixed arithmetic and conversions bewteen
> them are only possible as far as our knowledge of leap seconds
> allows. (The leap second information of traditional Unix time
> zone tables is unusable here, since they have no way of
> specifying "unknown leap second".)
>
> Additionally we should have time zone tables (without leap second
> information) for political time (also needing the ability to
> specify "unknown") to do conversions between "political text
> representations of time" and "wall clock" time. It also contains
> the completely predefined time zone "UTC".
I think it can be done much simpler. Conversion to/from political time
should simply take time zone offset as the parameter. This is how presently
Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
has all tables behind the function UTC_Time_Offset. The only problem is the
argument of the function. It must be UTC time instead of political one.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Time_Zones
2008-08-09 2:09 0% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-09 8:04 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2008-08-09 8:04 UTC (permalink / raw)
On Fri, 8 Aug 2008 21:09:42 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
>> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>>> ...
>>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>>> The package should provide Clock, +, -, <, <=, >, >=:
>>>
>>> I don't see how that could work. How would you display or create a UTC
>>> time?
>>
>> No problem:
>>
>> T : Ada.UTC_Time.Time := ...;
>> P : Ada.Calendar.Time := To_Calendar_Time (T);
>>
>> P is the political time corresponding to T, it is well-defined for each T.
>> P can be used in Ada.Calendar.Split to display T as:
>>
>> August 08, 2008 10:18 (Berlin time)
>>
>> When used in Ada.Calendar.Formatting.Split with
>>
>> Time_Zone => UTC_Time_Offset (T)
>>
>> the display could be:
>>
>> August 08, 2008 09:18 (UTC time)
>
> Sorry, this doesn't make any sense. Your original point, boiled down, is
> that it is never safe to convert from political time to UTC (because of the
> overlaps and holes). But then you go ahead and do exactly that.
It is safe in this case because it uses an external zone offset. The
conversion is unsafe when an attempt is made to determine the offset from
the political time itself. That is inconsistent. But when the offset is
determined by the UTC time, then everything is fine.
> In any case, if you were willing to require that, the current specification
> would work just fine for UTC time (because you could always get the UTC time
> directly from the record). In which case there is no problem, so we don't
> need an additional mechanism.
Yes, this is what GNAT does, at least under Windows.
My proposal would allow to have Ada.Calendar.Time really skewed as
politicians always whished (:-)). E.g.
T : Time := Time_Of (2008, 10, 28, 1.5*3600.0); -- 1h before the skew
then
T1 := T + 1.0*3600.0; -- 28.10.2008 02:30 before skew
T2 := T + 2.0*3600.0; -- 28.10.2008 02:30 after skew
T1 = T2 -- Political arithmetic!
A time defined this way will still be convertible forth and back to UTC
time, if you know the time offset. That is 1h for T1 and 2h for T2.
-----------
But in any case, RM should clarify what it means under political time. I.e.
whether T1 = T2 (= truly political time), or not (= hidden UTC time).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar.Time_Zones
2008-08-08 8:48 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-09 2:09 0% ` Randy Brukardt
2008-08-09 8:04 0% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Randy Brukardt @ 2008-08-09 2:09 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>> ...
>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>> The package should provide Clock, +, -, <, <=, >, >=:
>>
>> I don't see how that could work. How would you display or create a UTC
>> time?
>
> No problem:
>
> T : Ada.UTC_Time.Time := ...;
> P : Ada.Calendar.Time := To_Calendar_Time (T);
>
> P is the political time corresponding to T, it is well-defined for each T.
> P can be used in Ada.Calendar.Split to display T as:
>
> August 08, 2008 10:18 (Berlin time)
>
> When used in Ada.Calendar.Formatting.Split with
>
> Time_Zone => UTC_Time_Offset (T)
>
> the display could be:
>
> August 08, 2008 09:18 (UTC time)
Sorry, this doesn't make any sense. Your original point, boiled down, is
that it is never safe to convert from political time to UTC (because of the
overlaps and holes). But then you go ahead and do exactly that.
You could probably make it work if you somehow required Ada.Calendar.Time to
store UTC time + a time zone converter (that is, it isn't really political
time). But that would force a change in representation for most compiler's
Ada.Calendar.Time type, and most likely an increase in size as well. That
would really mess up existing programs that store binary representations of
Time (as Janus/Ada does internally).
In any case, if you were willing to require that, the current specification
would work just fine for UTC time (because you could always get the UTC time
directly from the record). In which case there is no problem, so we don't
need an additional mechanism.
...
>> Anyway, we should have this discussion on Ada-Comment, where it will get
>> recorded and attached to the eventual AI on the topic.
>
> Has the proposal any chance to made it?
I have no idea. I intend to put the mail and question into an AI and thus it
will be on the agenda in the future. Beyond that I cannot say.
I'm sure this exact proposal has no chance because it doesn't fix anything.
But a proposal that does fix something may be a different animal.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar.Time_Zones
@ 2008-08-08 8:48 7% ` Dmitry A. Kazakov
2008-08-09 2:09 0% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2008-08-08 8:48 UTC (permalink / raw)
On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
> ...
>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>> The package should provide Clock, +, -, <, <=, >, >=:
>
> I don't see how that could work. How would you display or create a UTC time?
No problem:
T : Ada.UTC_Time.Time := ...;
P : Ada.Calendar.Time := To_Calendar_Time (T);
P is the political time corresponding to T, it is well-defined for each T.
P can be used in Ada.Calendar.Split to display T as:
August 08, 2008 10:18 (Berlin time)
When used in Ada.Calendar.Formatting.Split with
Time_Zone => UTC_Time_Offset (T)
the display could be:
August 08, 2008 09:18 (UTC time)
Creating UTC time from UTC's Y/M/D/S should go as follows:
To_UTC_Time (Ada.Calendar.Formatting.Time_Of (Y/M/D/S, 0), 0);
> Anyway, we should have this discussion on Ada-Comment, where it will get
> recorded and attached to the eventual AI on the topic.
Has the proposal any chance to made it?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Time_Zones
2008-08-07 2:52 0% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-07 8:27 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2008-08-07 8:27 UTC (permalink / raw)
On Wed, 6 Aug 2008 21:52:53 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net...
>> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>>>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>>>
>>> It's as the RM says.
>>
>> But how to translate what it says into concrete numbers:
>>
>> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
>>
>> OK, I am posting that to Ada comments as you suggested.
>
> I don't think the RM answers your question, which technically means that it
> is unspecified.
Which perplexes me much. How could it happen that an Ada library function
has undefined behavior.
> It is reasonable to ask if it *ought* to be unspecified,
> which is why I asked you to ask the ARG.
Yes, I did.
>>> It's pretty obvious, though, that there is no way to do this correctly
>>> unless the time type is based on UTC (time-zone-less) time. And because
>>> of
>>> compatibility concerns, the only way to do that is to completely junk
>>> Ada.Calendar and start over, duplicating essentially everything. You're
>>> probably right that we should have done that, but it would always be a
>>> tough
>>> sell (lots of people would say that Ada.Calendar is "good enough") --
>>> which
>>> is why you need to ask this question directly to the ARG. (And get as
>>> many
>>> people as possible to support it, too.) I alone could never produce
>>> critical
>>> mass on this topic.
>>
>> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
>> Ada.Calendar.Formatting are all new packages. All of them have an
>> inconsistent semantics, because Time_Of is necessarily inconsistent [*].
>> Zone offset is simply not a function of the local time. It is of the UTC
>> time.
>
> You'd have to completely duplicate the contents of Ada.Calendar using a new,
> very similar time type that is based on UTC.
Hmm, is Ada.Calendar big? Anyway one didn't hesitate to duplicate most of
it in Ada.Calendar.Arithmetic.
But all that stuff like Time_Of etc is not really needed with UTC_Time. The
package should provide Clock, +, -, <, <=, >, >=:
package Ada.UTC_Time is
type UTC_Time is private;
function Clock return UTC_Time;
function "+" (Left : UTC_Time; Right : Duration) return UTC_Time;
function "+" (Left : Duration; Right : UTC_Time) return UTC_Time;
function "-" (Left : UTC_Time; Right : Duration) return UTC_Time;
function "-" (Left : UTC_Time; UTC_Time : Time) return Duration;
function "<" (Left, Right : UTC_Time) return Boolean;
function "<="(Left, Right : UTC_Time) return Boolean;
function ">" (Left, Right : UTC_Time) return Boolean;
function ">="(Left, Right : UTC_Time) return Boolean;
end Ada.UTC_Time;
That's it.
Then:
package Ada.UTC_Time.Time_Zones is
type Time_Offset is range -28*60 .. 28*60;
-- This is well-defined
function UTC_Time_Offset (Date : UTC_Time := Clock) return Time_Offset;
function To_Calendar_Time (Time : UTC_Time; Time_Zone) return Time;
function To_Calendar_Time (Time : UTC_Time; Time_Zone; Time_Offset)
return Time;
-- Time Zone is always required for the backward conversion
function To_UTC_Time (Time : Time; Time_Zone; Time_Offset)
return Time;
end Ada.UTC_Time.Time_Zones;
I would also like to see conversions between Ada.Real_Time.Time and
UTC_Time.
> The real question is whether the hole is important enough to try to fix
> (given that the fix is going require adding a lot more mechanism). That's a
> question I can't answer.
Our problem is that we need to exchange time-stamped data with the outside
world. So we have to convert UTC forth and back to Ada.Real_Time.Time. It
is to expect that the system might become out of service for when the clock
is adjusted. Considering similar cases, like air flight traffic control
systems dealing with GPS clock etc, I wonder how they would handle that.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar.Time_Zones
2008-08-05 9:10 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-07 2:52 0% ` Randy Brukardt
2008-08-07 8:27 0% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Randy Brukardt @ 2008-08-07 2:52 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net...
> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>>
>> It's as the RM says.
>
> But how to translate what it says into concrete numbers:
>
> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
>
> OK, I am posting that to Ada comments as you suggested.
I don't think the RM answers your question, which technically means that it
is unspecified. It is reasonable to ask if it *ought* to be unspecified,
which is why I asked you to ask the ARG.
>> It's pretty obvious, though, that there is no way to do this correctly
>> unless the time type is based on UTC (time-zone-less) time. And because
>> of
>> compatibility concerns, the only way to do that is to completely junk
>> Ada.Calendar and start over, duplicating essentially everything. You're
>> probably right that we should have done that, but it would always be a
>> tough
>> sell (lots of people would say that Ada.Calendar is "good enough") --
>> which
>> is why you need to ask this question directly to the ARG. (And get as
>> many
>> people as possible to support it, too.) I alone could never produce
>> critical
>> mass on this topic.
>
> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
> Ada.Calendar.Formatting are all new packages. All of them have an
> inconsistent semantics, because Time_Of is necessarily inconsistent [*].
> Zone offset is simply not a function of the local time. It is of the UTC
> time.
You'd have to completely duplicate the contents of Ada.Calendar using a new,
very similar time type that is based on UTC. That would have been a hard
sell (even if it would have made more sense, since Ada.Calendar.Arithmetic
probably would have been included directly as part of it). Your examples
make it clear that we should have done that, but we obviously failed to
notice that what we did instead doesn't quite work.
The real question is whether the hole is important enough to try to fix
(given that the fix is going require adding a lot more mechanism). That's a
question I can't answer.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Ada.Calendar.Time_Zones
@ 2008-08-05 9:10 7% ` Dmitry A. Kazakov
2008-08-07 2:52 0% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2008-08-05 9:10 UTC (permalink / raw)
On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>
> It's as the RM says.
But how to translate what it says into concrete numbers:
UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
OK, I am posting that to Ada comments as you suggested.
> It's pretty obvious, though, that there is no way to do this correctly
> unless the time type is based on UTC (time-zone-less) time. And because of
> compatibility concerns, the only way to do that is to completely junk
> Ada.Calendar and start over, duplicating essentially everything. You're
> probably right that we should have done that, but it would always be a tough
> sell (lots of people would say that Ada.Calendar is "good enough") -- which
> is why you need to ask this question directly to the ARG. (And get as many
> people as possible to support it, too.) I alone could never produce critical
> mass on this topic.
I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
Ada.Calendar.Formatting are all new packages. All of them have an
inconsistent semantics, because Time_Of is necessarily inconsistent [*].
Zone offset is simply not a function of the local time. It is of the UTC
time.
--------
* without additional parameters.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Missing Ada components in Ubuntu
2008-05-25 18:29 5% ` Sebastien Morand
@ 2008-05-26 1:28 0% ` Adrian Hoe
0 siblings, 0 replies; 104+ results
From: Adrian Hoe @ 2008-05-26 1:28 UTC (permalink / raw)
On May 26, 2:29 am, Sebastien Morand <seb.mor...@gmail.com> wrote:
> I just compiled AWS under ubuntu so I can help you.
>
> First, you have to compile gcc-4.3 because you can't compile aws-2.3.0 without
> it and there is no package in ubuntu.
> To compile gcc, you have to get the sources and configure the stuff be sure, to
> compile the ada langueage (it will be shown during configure).
> Afterwards you run make bootstrap and that's all.
>
> It's a bit long but it works.
>
> Then to compile aws and any ada stuff with gcc 4.3 you have to configure CC var.
> For instance :
> export CC=/usr/local/bin/gcc if gcc is installed in /usr/local (default)
>
> I recomand you to compile xmlada and asis if you want to.
>
> The thing is Ada.Calendar.Formatting is a library not implemented but in the
> version 4.3 ... so no choice to use it.
>
> I'll be happy to help you in any way if you have any problem compiling this stuff.
>
> And believe me, it worth it :-)
>
> Sebastien
>
There is gnat-4.3 in Ubuntu Intrepid. Have you tried that? I don't
know how to download and install from Intrepid. Any ideas?
http://packages.ubuntu.com/intrepid/devel/
--
Adrian Hoe
http://adrianhoe.com/adrianhoe/
^ permalink raw reply [relevance 0%]
* Re: Missing Ada components in Ubuntu
2008-05-25 15:22 6% Missing Ada components in Ubuntu Adrian Hoe
@ 2008-05-25 18:29 5% ` Sebastien Morand
2008-05-26 1:28 0% ` Adrian Hoe
0 siblings, 1 reply; 104+ results
From: Sebastien Morand @ 2008-05-25 18:29 UTC (permalink / raw)
I just compiled AWS under ubuntu so I can help you.
First, you have to compile gcc-4.3 because you can't compile aws-2.3.0 without
it and there is no package in ubuntu.
To compile gcc, you have to get the sources and configure the stuff be sure, to
compile the ada langueage (it will be shown during configure).
Afterwards you run make bootstrap and that's all.
It's a bit long but it works.
Then to compile aws and any ada stuff with gcc 4.3 you have to configure CC var.
For instance :
export CC=/usr/local/bin/gcc if gcc is installed in /usr/local (default)
I recomand you to compile xmlada and asis if you want to.
The thing is Ada.Calendar.Formatting is a library not implemented but in the
version 4.3 ... so no choice to use it.
I'll be happy to help you in any way if you have any problem compiling this stuff.
And believe me, it worth it :-)
Sebastien
> Hi,
>
> Sorry to trouble you, but I have no idea where I am supposed to post
> this. I have posted in Ubuntu forum and AWS list. I guess it will be
> no harm to post this here.
>
> I was trying to install AWS shared library packages by Ubuntu but it
> seemed there was a broken dependency. So I decided to build AWS
> myself.
>
> I got some errors and apparently, AWS could not find a-calfor.ad[sb]
> (Ada.Calendar.Formatting) and a-catizo.ad[sb]
> (Ada.Calendar.Time_Zones). AWS depends on these to build.
>
> Has anyone successfully build AWS on Ubuntu? Why these Ada packages
> are not included (or left out)? I can find these packages in gnat on
> Mac OS X.
>
> I am using both 32- and 64-bit Hardy Heron. Both gnat-4.1 and gnat-4.2
> have no such packages.
>
> Any ideas?
> --
> Adrian Hoe
> http://adrianhoe.com/adrianhoe/
^ permalink raw reply [relevance 5%]
* Missing Ada components in Ubuntu
@ 2008-05-25 15:22 6% Adrian Hoe
2008-05-25 18:29 5% ` Sebastien Morand
0 siblings, 1 reply; 104+ results
From: Adrian Hoe @ 2008-05-25 15:22 UTC (permalink / raw)
Hi,
Sorry to trouble you, but I have no idea where I am supposed to post
this. I have posted in Ubuntu forum and AWS list. I guess it will be
no harm to post this here.
I was trying to install AWS shared library packages by Ubuntu but it
seemed there was a broken dependency. So I decided to build AWS
myself.
I got some errors and apparently, AWS could not find a-calfor.ad[sb]
(Ada.Calendar.Formatting) and a-catizo.ad[sb]
(Ada.Calendar.Time_Zones). AWS depends on these to build.
Has anyone successfully build AWS on Ubuntu? Why these Ada packages
are not included (or left out)? I can find these packages in gnat on
Mac OS X.
I am using both 32- and 64-bit Hardy Heron. Both gnat-4.1 and gnat-4.2
have no such packages.
Any ideas?
--
Adrian Hoe
http://adrianhoe.com/adrianhoe/
^ permalink raw reply [relevance 6%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-26 11:53 6% ` Ludovic Brenta
@ 2008-04-27 21:41 7% ` Sebastien Morand
0 siblings, 0 replies; 104+ results
From: Sebastien Morand @ 2008-04-27 21:41 UTC (permalink / raw)
> I never intended gnat-4.2 to be the default on any architecture and
> Ubuntu diverges from Debian and risks breaking package dependencies.
> So, at this point, I am forced to recommend against Ubuntu 8.04 for
> Ada development. Previous versions are OK since they follow the
> policy for all Ada packages. If you want a stable Ada development
> platform, get Debian stable, which has "long term support" built in.
I'm quite agree with you, I successfully installed aws on freebsd recompiling
it, but I had to correct some stuff in the aws-2.3.0 and xmlada code . In any
case, I just was able to compile it with gcc43, because some standard ada
library were missing in gcc41 and gcc42.
Now, I just have to try it :-)
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-26 8:28 7% ` Georg Bauhaus
@ 2008-04-26 11:53 6% ` Ludovic Brenta
2008-04-27 21:41 7% ` Sebastien Morand
0 siblings, 1 reply; 104+ results
From: Ludovic Brenta @ 2008-04-26 11:53 UTC (permalink / raw)
Georg Bauhaus writes:
> Ludovic Brenta wrote:
>> Georg Bauhaus writes:
>>> 8.04 LTS has gnat-4.2.3 and libaws 2.2.
>>
>> Which are ABI incompatible with each other.
>
> Looking more closely, libaws2.2 depends on libgnat-4.1.
> This is resolved by Debian's package system. (libaws2.2
> claims to depend on libldap2, too, which is not available
> with Ubuntu 8.04 LTS at this time.)
Talk about a "professional" distribution :)
> The unnumbered package "gnat" will install GNAT 4.2.3.
I don't know what Ubuntu changed to gcc-defaults but, in Debian, in
gcc-defaults version 1.64 I made gnat-4.3 the default on all
architectures; version 1.66 reverted to gnat-4.2 on alpha, mips and
mipsel without consulting with me, and 1.70 finally reverted that,
thereby completing the transition to gnat-4.3 as the default on all
architectures.
I never intended gnat-4.2 to be the default on any architecture and
Ubuntu diverges from Debian and risks breaking package dependencies.
So, at this point, I am forced to recommend against Ubuntu 8.04 for
Ada development. Previous versions are OK since they follow the
policy for all Ada packages. If you want a stable Ada development
platform, get Debian stable, which has "long term support" built in.
--
Ludovic Brenta.
^ permalink raw reply [relevance 6%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 21:07 7% ` Ludovic Brenta
@ 2008-04-26 8:28 7% ` Georg Bauhaus
2008-04-26 11:53 6% ` Ludovic Brenta
0 siblings, 1 reply; 104+ results
From: Georg Bauhaus @ 2008-04-26 8:28 UTC (permalink / raw)
Ludovic Brenta wrote:
> Georg Bauhaus writes:
>> 8.04 LTS has gnat-4.2.3 and libaws 2.2.
>
> Which are ABI incompatible with each other.
Looking more closely, libaws2.2 depends on libgnat-4.1.
This is resolved by Debian's package system. (libaws2.2
claims to depend on libldap2, too, which is not available
with Ubuntu 8.04 LTS at this time.)
The unnumbered package "gnat" will install GNAT 4.2.3.
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 15:43 7% ` Georg Bauhaus
@ 2008-04-25 21:07 7% ` Ludovic Brenta
2008-04-26 8:28 7% ` Georg Bauhaus
0 siblings, 1 reply; 104+ results
From: Ludovic Brenta @ 2008-04-25 21:07 UTC (permalink / raw)
Georg Bauhaus writes:
> Ludovic Brenta wrote:
>
>> If you're going to be "professional", you should use the packages that
>> come with the "professional" distro. So, your best option is to fall
>> back on libaws-dev 2.2 and gnat-4.1 which come as part of Ubuntu. The
>> version after today's 8.04 will probably have gnat-4.3 and libaws 2.3.
>
> 8.04 LTS has gnat-4.2.3 and libaws 2.2.
Which are ABI incompatible with each other.
--
Ludovic Brenta.
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 8:16 7% ` Ludovic Brenta
2008-04-25 8:47 7% ` Sébastien
@ 2008-04-25 15:43 7% ` Georg Bauhaus
2008-04-25 21:07 7% ` Ludovic Brenta
1 sibling, 1 reply; 104+ results
From: Georg Bauhaus @ 2008-04-25 15:43 UTC (permalink / raw)
Ludovic Brenta wrote:
> If you're going to be "professional", you should use the packages that
> come with the "professional" distro. So, your best option is to fall
> back on libaws-dev 2.2 and gnat-4.1 which come as part of Ubuntu. The
> version after today's 8.04 will probably have gnat-4.3 and libaws 2.3.
8.04 LTS has gnat-4.2.3 and libaws 2.2.
^ permalink raw reply [relevance 7%]
* Re: Missing Standard lib in gnat
2008-04-25 8:49 7% issing Standard lib in gnat Sébastien
@ 2008-04-25 9:35 6% ` Ludovic Brenta
0 siblings, 0 replies; 104+ results
From: Ludovic Brenta @ 2008-04-25 9:35 UTC (permalink / raw)
Sébastien wrote:
> Hi,
>
> I'm using gnat-4.1 and I found out some standard libs are missing:
>
> try the following sample test:
>
> with Ada.Calendar.Formatting;
>
> procedure test is
> begin
> Ada.Text_IO.Put_Line("test");
> end test;
>
> And get at compile time:
> mscm@routeur:~/gnat/aws$ gcc -gnat05 -c test.adb
> test.adb:1:06: "ada.calendar.formatting" is not a predefined library unit
>
> So is there a lot of missing stuff in gnat?
gnat-4.1 supports all of Ada 95 but only a few Ada 2005 features. More
features were added in gnat-4,2 and still more in gnat-4.3.
Ada.Calendar.Formatting is one of the units that only appeared in
gnat-4.3. In the mean time, GNAT.Calendar.Time_IO might provide what
you need.
--
Ludovic Brenta.
^ permalink raw reply [relevance 6%]
* issing Standard lib in gnat
@ 2008-04-25 8:49 7% Sébastien
2008-04-25 9:35 6% ` Missing " Ludovic Brenta
0 siblings, 1 reply; 104+ results
From: Sébastien @ 2008-04-25 8:49 UTC (permalink / raw)
Hi,
I'm using gnat-4.1 and I found out some standard libs are missing:
try the following sample test:
with Ada.Calendar.Formatting;
procedure test is
begin
Ada.Text_IO.Put_Line("test");
end test;
And get at compile time:
mscm@routeur:~/gnat/aws$ gcc -gnat05 -c test.adb
test.adb:1:06: "ada.calendar.formatting" is not a predefined library unit
So is there a lot of missing stuff in gnat?
Sebastien
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 8:16 7% ` Ludovic Brenta
@ 2008-04-25 8:47 7% ` Sébastien
2008-04-25 15:43 7% ` Georg Bauhaus
1 sibling, 0 replies; 104+ results
From: Sébastien @ 2008-04-25 8:47 UTC (permalink / raw)
> If you're going to be "professional", you should use the packages that
> come with the "professional" distro. So, your best option is to fall
> back on libaws-dev 2.2 and gnat-4.1 which come as part of Ubuntu. The
> version after today's 8.04 will probably have gnat-4.3 and libaws 2.3.
You are completly right, I didn't even check if there was some compiled
version. I'm going to open an other thread about missing standard lib
stuff anyway :-)
Thanks for you help.
Sebastien
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 7:44 7% ` Sebastien Morand
@ 2008-04-25 8:16 7% ` Ludovic Brenta
2008-04-25 8:47 7% ` Sébastien
2008-04-25 15:43 7% ` Georg Bauhaus
0 siblings, 2 replies; 104+ results
From: Ludovic Brenta @ 2008-04-25 8:16 UTC (permalink / raw)
Sebastien Morand wrote:
> > <plug>
> > Alternatively, switch to Debian which has gnat-4.3 in testing, and
> > participate in upgrading the existing libaws 2.2 package to 2.3 :)
> > </plug>
>
> I'm under ubuntu and that's a professional machine, so I can't (and really I would).
If you're going to be "professional", you should use the packages that
come with the "professional" distro. So, your best option is to fall
back on libaws-dev 2.2 and gnat-4.1 which come as part of Ubuntu. The
version after today's 8.04 will probably have gnat-4.3 and libaws 2.3.
> At home, I'm using FreeBSD, I'll give a try tonight.
>
> Sebastien
--
Ludovic Brenta.
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-25 7:38 7% ` Ludovic Brenta
@ 2008-04-25 7:44 7% ` Sebastien Morand
2008-04-25 8:16 7% ` Ludovic Brenta
0 siblings, 1 reply; 104+ results
From: Sebastien Morand @ 2008-04-25 7:44 UTC (permalink / raw)
> <plug>
> Alternatively, switch to Debian which has gnat-4.3 in testing, and
> participate in upgrading the existing libaws 2.2 package to 2.3 :)
> </plug>
I'm under ubuntu and that's a professional machine, so I can't (and really I would).
At home, I'm using FreeBSD, I'll give a try tonight.
Sebastien
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-24 17:12 7% ` Tero Koskinen
@ 2008-04-25 7:38 7% ` Ludovic Brenta
2008-04-25 7:44 7% ` Sebastien Morand
0 siblings, 1 reply; 104+ results
From: Ludovic Brenta @ 2008-04-25 7:38 UTC (permalink / raw)
Tero Koskinen wrote:
> Hello,
>
> On Thu, 24 Apr 2008 16:29:31 +0000 S�bastien wrote:
> > Hi,
> >
> > When I try to compile aws, I get the following message:
> > /var/local/mscm/gnat/aws/AWS-gpl-2.3.0/src/aws-services-dispatchers-timer.adb
> > aws-services-dispatchers-timer.ads:31:06: "ADA.CALENDAR.FORMATTING" is
> > not a predefined library unit
> >
> > I'm under ubuntu, and it looks like something is missing in gnat, how to
> > fix it?
> >
> > GNAT 4.2.1 (Ubuntu 4.2.1-5ubuntu6)
>
> GNAT 4.2.1 does not fully support all Ada 2005 features.
>
> Try FSF GNAT 4.3 or GNAT GPL 2007. They have better support.
> Alternatively, use AWS 2.2.0. It should compile with GNAT 4.2.1.
<plug>
Alternatively, switch to Debian which has gnat-4.3 in testing, and
participate in upgrading the existing libaws 2.2 package to 2.3 :)
</plug>
--
Ludovic Brenta.
^ permalink raw reply [relevance 7%]
* Re: gnat : "ada.calendar.formatting" is not a predefined library
2008-04-24 16:29 13% gnat : "ada.calendar.formatting" is not a predefined library Sébastien
@ 2008-04-24 17:12 7% ` Tero Koskinen
2008-04-25 7:38 7% ` Ludovic Brenta
0 siblings, 1 reply; 104+ results
From: Tero Koskinen @ 2008-04-24 17:12 UTC (permalink / raw)
Hello,
On Thu, 24 Apr 2008 16:29:31 +0000 Sébastien wrote:
> Hi,
>
> When I try to compile aws, I get the following message:
> /var/local/mscm/gnat/aws/AWS-gpl-2.3.0/src/aws-services-dispatchers-timer.adb
> aws-services-dispatchers-timer.ads:31:06: "ADA.CALENDAR.FORMATTING" is
> not a predefined library unit
>
> I'm under ubuntu, and it looks like something is missing in gnat, how to
> fix it?
>
> GNAT 4.2.1 (Ubuntu 4.2.1-5ubuntu6)
GNAT 4.2.1 does not fully support all Ada 2005 features.
Try FSF GNAT 4.3 or GNAT GPL 2007. They have better support.
Alternatively, use AWS 2.2.0. It should compile with GNAT 4.2.1.
--
Tero Koskinen - http://iki.fi/tero.koskinen/
^ permalink raw reply [relevance 7%]
* gnat : "ada.calendar.formatting" is not a predefined library
@ 2008-04-24 16:29 13% Sébastien
2008-04-24 17:12 7% ` Tero Koskinen
0 siblings, 1 reply; 104+ results
From: Sébastien @ 2008-04-24 16:29 UTC (permalink / raw)
Hi,
When I try to compile aws, I get the following message:
mscm@routeur:~/gnat/aws/AWS-gpl-2.3.0$ make build
Building libz.a (Zlib library)
gnatmake: objects up to date.
gnatmake: objects up to date.
gcc-4.2 -c -gnat05 -gnatwcfijkmruv -gnaty3abcefhiklmnoprstx -Wall -O2
-gnatn -I- -gnatA
/var/local/mscm/gnat/aws/AWS-gpl-2.3.0/src/aws-services-dispatchers-timer.adb
aws-services-dispatchers-timer.ads:31:06: "ADA.CALENDAR.FORMATTING" is
not a predefined library unit
aws-services-dispatchers-timer.ads:31:06:
"AWS.SERVICES.DISPATCHERS.TIMER (body)" depends on
"AWS.SERVICES.DISPATCHERS.TIMER (spec)"
aws-services-dispatchers-timer.ads:31:06:
"AWS.SERVICES.DISPATCHERS.TIMER (spec)" depends on
"ADA.CALENDAR.FORMATTING (spec)"
gnatmake:
"/var/local/mscm/gnat/aws/AWS-gpl-2.3.0/src/aws-services-dispatchers-timer.adb"
compilation error
make[1]: *** [build] Error 4
make: *** [src_build] Error 2
I try the following sample test:
with Ada.Calendar.Formatting;
procedure test is
begin
Ada.Text_IO.Put_Line("test");
end test;
And get at compile time:
mscm@routeur:~/gnat/aws$ gcc -gnat05 -c test.adb
test.adb:1:06: "ada.calendar.formatting" is not a predefined library unit
I'm under ubuntu, and it looks like something is missing in gnat, how to
fix it?
I'm using :
mscm@routeur:~/gnat/aws$ gnat
GNAT 4.2.1 (Ubuntu 4.2.1-5ubuntu6)
Copyright 1996-2006, Free Software Foundation, Inc.
Thanks,
Sebastien
^ permalink raw reply [relevance 13%]
* Re: delay until problem in Windows
@ 2008-04-09 14:56 8% ` george.priv
0 siblings, 0 replies; 104+ results
From: george.priv @ 2008-04-09 14:56 UTC (permalink / raw)
On Apr 7, 3:25 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 6 Apr 2008 20:10:38 -0700 (PDT), george.p...@gmail.com wrote:
> > On Apr 5, 6:51 pm, george.p...@gmail.com wrote:
>
> [...]
>
> > with Ada.Calendar;
> > use Ada.Calendar;
>
> I don't know the implementation of, but Ada.Calendar is a political time,
> influenced by the time synchronization stuff. What happens if you replace
> it by Ada.Real_Time?
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
You were right: so far the Real_Time version is running for 48 hours
without failing. So that may be a workaround.
with Ada.Real_Time;
use Ada.Real_Time;
with Ada.Text_IO;
use Ada.Text_IO;
--with Ada.RealFormatting;
with Ada.Calendar.Formatting;
procedure Delay_RT is
Start_Time : Time := Clock;
Time_Failed : Time := Start_Time;
ST : Ada.Calendar.Time := Ada.Calendar.Clock;
FT : Ada.Calendar.Time := ST;
task Delay_Test_Tsk is
entry Term;
end Delay_Test_Tsk;
task body Delay_Test_Tsk is
DT : constant Time_Span := Seconds (10); -- Desired
Delta T
Time_For_Next : Time := Clock + DT; -- Next
cycle
Last : Time := Clock; -- Last
cycle clocked
Fail_Count : Natural := 0;
begin
while Fail_Count < 5 loop
select
accept Term;
exit;
or
delay until Time_For_Next;
declare
Actual_Delta : Time_Span := Clock - Last;
begin
Last := Clock;
Time_For_Next := Last + DT;
Put_Line("Actual Delay: " & Duration'Image(To_Duration(
Actual_Delta))
& ", Running (h):"
& Duration'Image(To_Duration(Clock - Start_Time)/
3600.0));
if Actual_Delta < DT or Actual_Delta > (DT +
Seconds(1)) then
if Fail_Count = 0 then
Time_Failed := Clock;
FT := Ada.Calendar.Clock;
end if;
Fail_Count := Fail_Count + 1;
else
Fail_Count := 0;
end if;
end;
end select;
end loop;
Put_Line("Started at:" & Ada.Calendar.Formatting.Image(ST));
if Time_Failed /= Start_Time then
Put_Line("Failed at :" & Ada.Calendar.Formatting.Image(FT));
Put_Line("Failed after :" & Duration'Image(To_Duration(
Time_Failed -
Start_Time)));
end if;
end Delay_Test_Tsk;
Line : String (1 .. 80);
Last : Natural;
begin
loop
Get_Line(Line, Last);
exit when Line(1) = 'q' or Line(1) = 'Q';
end loop;
Delay_Test_Tsk.Term;
end Delay_RT;
^ permalink raw reply [relevance 8%]
* Re: delay until problem in Windows
@ 2008-04-07 3:10 6% ` george.priv
0 siblings, 1 reply; 104+ results
From: george.priv @ 2008-04-07 3:10 UTC (permalink / raw)
On Apr 5, 6:51 pm, george.p...@gmail.com wrote:
Little update on the issue. The following program was created to
reproduce the problem:
with Ada.Calendar;
use Ada.Calendar;
with Ada.Text_IO;
use Ada.Text_IO;
with Ada.Calendar.Formatting;
use Ada.Calendar.Formatting;
procedure Delay_Test is
Start_Time : Time := Clock;
Time_Failed : Time := Start_Time; -- Time of first failure
encountered
task Delay_Test_Tsk is
entry Term;
end Delay_Test_Tsk;
task body Delay_Test_Tsk is
DT : constant Duration := 10.0; -- Desired
Delta T
Time_For_Next : Time := Clock + DT; -- Next cycle
Last : Time := Clock; -- Last cycle
clocked
Fail_Count : Natural := 0;
begin
while Fail_Count < 5 loop
select
accept Term;
exit;
or
delay until Time_For_Next;
declare
Actual_Delta : Duration := Clock - Last;
begin
Last := Clock;
Time_For_Next := Last + DT;
Put_Line("Actual Delay: " &
Duration'Image(Actual_Delta)
& ", Running (h):"
& Duration'Image((Clock - Start_Time)/3600.0));
if Actual_Delta < DT then
if Fail_Count = 0 then
Time_Failed := Clock;
end if;
Fail_Count := Fail_Count + 1;
else
Fail_Count := 0;
end if;
end;
end select;
end loop;
Put_Line("Started at:" & Image(Start_Time));
if Time_Failed /= Start_Time then
Put_Line("Failed at :" & Image(Time_Failed));
Put_Line("Failed after :" & Duration'Image(Time_Failed -
Start_Time));
end if;
end Delay_Test_Tsk;
Line : String (1 .. 80);
Last : Natural;
begin
loop
Get_Line(Line, Last);
exit when Line(1) = 'q' or Line(1) = 'Q';
end loop;
Delay_Test_Tsk.Term;
end Delay_Test;
Results vary from Windows flavors and I am not sure also that it is
not related to a particular hardware. So far it is fine on Vista
(after 22 hours) and XP (10 Hours). It failed on Server 2003 after 12
hours see output:
Actual Delay: 10.000372615, Running (h): 11.836564300
Actual Delay: 10.000381345, Running (h): 11.839342185
Actual Delay: 10.000370677, Running (h): 11.842120066
Actual Delay: 10.000379534, Running (h): 11.844897949
Actual Delay: 10.000372998, Running (h): 11.847675831
Actual Delay: 10.000545537, Running (h): 11.850453761
Actual Delay: 7.984454967, Running (h): 11.852675966
Actual Delay: 7.984806621, Running (h): 11.854893969
Actual Delay: 7.984636928, Running (h): 11.857111924
Actual Delay: 7.984678819, Running (h): 11.859329891
Actual Delay: 7.984673656, Running (h): 11.861547856
Started at:2008-04-06 07:14:09
Failed at :2008-04-06 19:05:18
Failed after : 42669.633539129
If anyone would like to check their systems and let us know?
^ permalink raw reply [relevance 6%]
* Re: Real Time IO routines
@ 2007-10-26 17:12 6% ` Ed Falis
0 siblings, 0 replies; 104+ results
From: Ed Falis @ 2007-10-26 17:12 UTC (permalink / raw)
On Fri, 26 Oct 2007 10:58:59 -0400, andrew <andrew.carroll@okstate.edu>
wrote:
> Hello,
>
> Is there a put or put_line procedure to output the value of variables
> declared as the Time type defined in the Real_Time package?
>
If you're using Ada 2005 (eg an appropriate version of GNAT),
Ada.Calendar.Formatting provides an Image routine that gives a string
representation of Time. This can then be used with Text_IO.
^ permalink raw reply [relevance 6%]
* AW: Getting current date and time
2007-07-25 7:26 7% ` Maciej Sobczak
@ 2007-07-25 7:42 0% ` Grein, Christoph (Fa. ESG)
0 siblings, 0 replies; 104+ results
From: Grein, Christoph (Fa. ESG) @ 2007-07-25 7:42 UTC (permalink / raw)
To: comp.lang.ada
> On my system Ada.Calendar.Time_Of and Ada.Calendar.Formatting.Time_Of
> behave *differenty* with the same arguments, so with such a mess
> already in the library no additional proposal could hurt...
If you mean a difference of 23 s, this is the number of leap seconds
since 1972.
Check the constant Leap_Support in Ada.Calendar'Body in your compiler
version of GNAT, it should be False in order to ignore the leap seconds.
Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
CONFIDENTIALITY NOTICE
This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
@ 2007-07-25 7:26 7% ` Maciej Sobczak
2007-07-25 7:42 0% ` AW: " Grein, Christoph (Fa. ESG)
0 siblings, 1 reply; 104+ results
From: Maciej Sobczak @ 2007-07-25 7:26 UTC (permalink / raw)
On 24 Lip, 17:24, Adam Beneschan <a...@irvine.com> wrote:
> > The problem is that I need just a number of seconds (this is for
> > interfacing with other software which uses that Unix-like time
> > descriptions), so I cannot use the value which is broken down into
> > several components.
>
> Why not? Differences returns the result in "days" and "seconds", and
> you should be able to convert the "days" to seconds by multiplying it
> by a value that I just recently helped my 9-year-old figure out, and
> then adding the result to the second value, and then maybe adding the
> leap seconds (see below).
Right. I didn't notice that it's just two components, not more
(without years, months and days).
> We could
> conceivably propose a new addition to Ada.Calendar.Arithmetic:
>
> function
> Return_Current_Time_However_The_Other_Software_Maciej_Is_Using_Does_It;
>
> but I sort of doubt that a proposal like that would be accepted.
On my system Ada.Calendar.Time_Of and Ada.Calendar.Formatting.Time_Of
behave *differenty* with the same arguments, so with such a mess
already in the library no additional proposal could hurt...
Thank you for pointing me in the right direction, I was able now to
get the expected values by using Ada.Calendar.Formatting.Time_Of.
--
Maciej Sobczak
http://www.msobczak.com/
^ permalink raw reply [relevance 7%]
* Re: Getting current date and time
2007-07-22 23:00 7% ` Martin
@ 2007-07-23 15:24 0% ` koburtch
1 sibling, 0 replies; 104+ results
From: koburtch @ 2007-07-23 15:24 UTC (permalink / raw)
On Jul 22, 7:00 pm, Martin <martin.do...@btopenworld.com> wrote:
> On 22 Jul, 22:21, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>
> > It looks like there is no standard package for handling current time
> > and date and operations of these entities.
>
> > What are the available solutions?
>
> > --
> > Maciej Sobczakhttp://www.msobczak.com/
>
> Ada.Calendar
>
> or if you have an Ada2005 compiler
>
> Ada.Calendar + Ada.Calendar.Arithmetic, Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones
>
> Cheers
> -- Martin
You can see an example in my Big Online Book of Linux Ada Programming
at http://www.pegasoft.ca/boblap.html in Section 12.6.
Ken B.
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
@ 2007-07-22 23:00 7% ` Martin
2007-07-23 15:24 0% ` koburtch
0 siblings, 2 replies; 104+ results
From: Martin @ 2007-07-22 23:00 UTC (permalink / raw)
On 22 Jul, 22:21, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> It looks like there is no standard package for handling current time
> and date and operations of these entities.
>
> What are the available solutions?
>
> --
> Maciej Sobczakhttp://www.msobczak.com/
Ada.Calendar
or if you have an Ada2005 compiler
Ada.Calendar + Ada.Calendar.Arithmetic, Ada.Calendar.Formatting and
Ada.Calendar.Time_Zones
Cheers
-- Martin
^ permalink raw reply [relevance 7%]
* AW: Ada.Calendar.Formatting.Image
[not found] <0367891DA5DA7E408D42A860FA002F448D62CA@sma2901.cr.eurocopter.corp>
@ 2007-06-15 8:12 5% ` Grein, Christoph (Fa. ESG)
0 siblings, 0 replies; 104+ results
From: Grein, Christoph (Fa. ESG) @ 2007-06-15 8:12 UTC (permalink / raw)
To: comp.lang.ada
With the newest supported version GNAT Pro 6.0.1, this does not occur.
In
package Calendar body, there is a constant Leap_Support, and if this is
False, you don't GET the 23 s difference caused by the number of leap
seconds since 1972.
(Oops: Forgot GET in last message.)
Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
CONFIDENTIALITY NOTICE
This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
^ permalink raw reply [relevance 5%]
* AW: AW: Ada.Calendar.Formatting.Image
2007-06-15 4:36 7% ` Jeffrey R. Carter
@ 2007-06-15 5:46 5% ` Grein, Christoph (Fa. ESG)
0 siblings, 0 replies; 104+ results
From: Grein, Christoph (Fa. ESG) @ 2007-06-15 5:46 UTC (permalink / raw)
To: comp.lang.ada
I did send this to AdaCore (normally, I do not spill their mailbox with
CLA questions, but here I was concerned about our time measurements
we'll perform pretty soon).
With the newest supported version GNAT Pro 6.0.1, this does not occur (I
was wrong in my first post, this was with a previous version). In
package Calendar body, there is a constant Leap_Support, and if this is
False, you don't the 23 s difference caused by the number of leap
seconds since 1972.
Leap_Second_Dates: constant array (1 .. Leap_Seconds_Count) of
Leap_Second_Date :=
((1972, 6, 30), (1972, 12, 31), (1973, 12, 31), (1974, 12, 31),
(1975, 12, 31), (1976, 12, 31), (1977, 12, 31), (1978, 12, 31),
(1979, 12, 31), (1981, 6, 30), (1982, 6, 30), (1983, 6, 30),
(1985, 6, 30), (1987, 12, 31), (1989, 12, 31), (1990, 12, 31),
(1992, 6, 30), (1993, 6, 30), (1994, 6, 30), (1995, 12, 31),
(1997, 6, 30), (1998, 12, 31), (2005, 12, 31));
Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
CONFIDENTIALITY NOTICE
This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
^ permalink raw reply [relevance 5%]
* Re: AW: Ada.Calendar.Formatting.Image
2007-06-14 5:33 5% ` AW: Ada.Calendar.Formatting.Image Grein, Christoph (Fa. ESG)
2007-06-14 16:53 7% ` tmoran
2007-06-14 21:49 7% ` Per Sandberg
@ 2007-06-15 4:37 7% ` Jeffrey R. Carter
2 siblings, 0 replies; 104+ results
From: Jeffrey R. Carter @ 2007-06-15 4:37 UTC (permalink / raw)
Grein, Christoph (Fa. ESG) wrote:
> I get the same difference with GNAT Pro 6.0.1:
>
> Time_Offset 120
> 2007 6 14 7 28 22 0.206127000
> 2007-06-14 05:27:59.21
> 2007-06-14 07:27:59.21
Interesting. As a supported user, perhaps you could inquire of AdaCore
about this.
--
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18
^ permalink raw reply [relevance 7%]
* AW: Ada.Calendar.Formatting.Image
2007-06-14 16:53 7% ` tmoran
2007-06-15 4:36 7% ` Jeffrey R. Carter
@ 2007-06-15 4:37 5% ` Grein, Christoph (Fa. ESG)
1 sibling, 0 replies; 104+ results
From: Grein, Christoph (Fa. ESG) @ 2007-06-15 4:37 UTC (permalink / raw)
To: comp.lang.ada
No, it's the number of leap seconds since 1972. See Ada.Calendar body.
Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
CONFIDENTIALITY NOTICE
This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
^ permalink raw reply [relevance 5%]
* Re: AW: Ada.Calendar.Formatting.Image
2007-06-14 16:53 7% ` tmoran
@ 2007-06-15 4:36 7% ` Jeffrey R. Carter
2007-06-15 5:46 5% ` AW: " Grein, Christoph (Fa. ESG)
2007-06-15 4:37 5% ` Grein, Christoph (Fa. ESG)
1 sibling, 1 reply; 104+ results
From: Jeffrey R. Carter @ 2007-06-15 4:36 UTC (permalink / raw)
tmoran@acm.org wrote:
>> 2007 6 14 7 28 22 0.206127000
>> 2007-06-14 05:27:59.21
>
> Possibly relevant fact:
> If the clock tick is 10E-11, then 2**32 ticks would be about 23 seconds.
That doesn't seem relevant here. The difference is the values obtained
using Split and Image for the same Clock value.
--
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18
^ permalink raw reply [relevance 7%]
* Re: AW: Ada.Calendar.Formatting.Image
2007-06-14 5:33 5% ` AW: Ada.Calendar.Formatting.Image Grein, Christoph (Fa. ESG)
2007-06-14 16:53 7% ` tmoran
@ 2007-06-14 21:49 7% ` Per Sandberg
2007-06-15 4:37 7% ` Jeffrey R. Carter
2 siblings, 0 replies; 104+ results
From: Per Sandberg @ 2007-06-14 21:49 UTC (permalink / raw)
Have you sent a note to AdaCore??
/Per
Grein, Christoph (Fa. ESG) wrote:
> I get the same difference with GNAT Pro 6.0.1:
>
> Time_Offset 120
> 2007 6 14 7 28 22 0.206127000
> 2007-06-14 05:27:59.21
> 2007-06-14 07:27:59.21
>
>
> Eurocopter Deutschland GmbH
> Sitz der Gesellschaft/Registered Office: Donauwoerth
> Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
> Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
> Geschaeftsfuehrung/Board of Management:
> Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
>
> CONFIDENTIALITY NOTICE
>
> This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
> If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
> It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
>
^ permalink raw reply [relevance 7%]
* AW: Ada.Calendar.Formatting.Image
2007-06-14 5:33 5% ` AW: Ada.Calendar.Formatting.Image Grein, Christoph (Fa. ESG)
@ 2007-06-14 16:53 7% ` tmoran
2007-06-15 4:36 7% ` Jeffrey R. Carter
2007-06-15 4:37 5% ` Grein, Christoph (Fa. ESG)
2007-06-14 21:49 7% ` Per Sandberg
2007-06-15 4:37 7% ` Jeffrey R. Carter
2 siblings, 2 replies; 104+ results
From: tmoran @ 2007-06-14 16:53 UTC (permalink / raw)
> 2007 6 14 7 28 22 0.206127000
> 2007-06-14 05:27:59.21
Possibly relevant fact:
If the clock tick is 10E-11, then 2**32 ticks would be about 23 seconds.
^ permalink raw reply [relevance 7%]
* AW: Ada.Calendar.Formatting.Image
2007-06-13 23:19 14% Ada.Calendar.Formatting.Image Jeffrey R. Carter
@ 2007-06-14 5:33 5% ` Grein, Christoph (Fa. ESG)
2007-06-14 16:53 7% ` tmoran
` (2 more replies)
0 siblings, 3 replies; 104+ results
From: Grein, Christoph (Fa. ESG) @ 2007-06-14 5:33 UTC (permalink / raw)
To: comp.lang.ada
I get the same difference with GNAT Pro 6.0.1:
Time_Offset 120
2007 6 14 7 28 22 0.206127000
2007-06-14 05:27:59.21
2007-06-14 07:27:59.21
Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
CONFIDENTIALITY NOTICE
This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful.
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much.
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
^ permalink raw reply [relevance 5%]
* Ada.Calendar.Formatting.Image
@ 2007-06-13 23:19 14% Jeffrey R. Carter
2007-06-14 5:33 5% ` AW: Ada.Calendar.Formatting.Image Grein, Christoph (Fa. ESG)
0 siblings, 1 reply; 104+ results
From: Jeffrey R. Carter @ 2007-06-13 23:19 UTC (permalink / raw)
Here's a little test program:
with Ada.Calendar.Formatting;
with Ada.Text_IO;
procedure Time_Test is
Time : constant Ada.Calendar.Time := Ada.Calendar.Clock;
Year : Positive;
Month : Positive;
Day : Positive;
Hour : Natural;
Minute : Natural;
Second : Natural;
Sub_Sec : Duration;
Seconds : Duration;
begin -- Time_Test
Ada.Calendar.Split (Date => Time,
Year => Year,
Month => Month,
Day => Day,
Seconds => Seconds);
Ada.Calendar.Formatting.Split (Seconds => Seconds,
Hour => Hour,
Minute => Minute,
Second => Second,
Sub_Second => Sub_Sec);
Ada.Text_IO.Put_Line (Item => Integer'Image (Year) &
Integer'Image (Month) &
Integer'Image (Day) &
Integer'Image (Hour) &
Integer'Image (Minute) &
Integer'Image (Second) &
Duration'Image (Sub_Sec) );
Ada.Text_IO.Put_Line (Item => Ada.Calendar.Formatting.Image (Time) );
end Time_Test;
Using GNAT GPL 2007 on a Linux/x86 platform with system time set to MST
(-0700), this outputs
2007 6 13 15 46 20 0.415945000
2007-06-13 22:45:57
Is the ~23 sec difference correct, or is this an error in Image?
--
Jeff Carter
"Sir Robin the-not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68
^ permalink raw reply [relevance 14%]
* Re: Extended 'Succ attribute?
@ 2006-11-24 13:02 7% ` Peter Hermann
0 siblings, 0 replies; 104+ results
From: Peter Hermann @ 2006-11-24 13:02 UTC (permalink / raw)
Adam Beneschan <adam@irvine.com> wrote:
> J?r?mie Lumbroso wrote:
[snip all]
I agree 100% to Adam Benescha.
Moreover, my experience says, that array accesses are fastest.
However, that still depends on tests.
I played around with the following:
-- package Ada.Calendar.Formatting is
-- -- Day of the week:
-- type Day_Name is (Monday, Tuesday, Wednesday, Thursday,
-- Friday, Saturday, Sunday);
-- function Day_of_Week (Date : Time) return Day_Name;
with Ada.Calendar.Formatting;
use Ada.Calendar.Formatting;
with ada.text_io;
procedure ada2005calendartest3ph is
type next_day_type is array(day_name) of day_name;
next_day : next_day_type :=
(Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, Monday);
specimen : day_name := Friday;
begin
ada.text_io.put_line("starting program ada2005calendartest3ph");
for i in 1..9 loop
ada.text_io.put_line(day_name'image(specimen));
specimen:=next_day(specimen);
end loop;
--result:
--starting program ada2005calendartest3ph
--FRIDAY
--SATURDAY
--SUNDAY
--MONDAY
--TUESDAY
--WEDNESDAY
--THURSDAY
--FRIDAY
--SATURDAY
end ada2005calendartest3ph; --20061124ph
--
--Peter.Hermann@ihr.uni-stuttgart.de (+49)0711-685-872-44(Fax79)
--Nobelstr.19 Raum 0.030, D-70569 Stuttgart IHR Hoechstleistungsrechnen
--http://www.ihr.uni-stuttgart.de/
^ permalink raw reply [relevance 7%]
* Re: Timing Block of GNAT code in milliseconds
2005-04-29 20:52 8% ` Randy Brukardt
@ 2005-04-30 10:02 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
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 [relevance 0%]
* Re: Timing Block of GNAT code in milliseconds
@ 2005-04-29 20:52 8% ` Randy Brukardt
2005-04-30 10:02 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
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 [relevance 8%]
* Re: Inserting Calendar.Time in a database
2004-08-06 9:28 0% ` Martin Dowie
@ 2004-08-06 10:44 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 104+ results
From: Dmitry A. Kazakov @ 2004-08-06 10:44 UTC (permalink / raw)
On Fri, 6 Aug 2004 10:28:58 +0100, Martin Dowie wrote:
> Dmitry A. Kazakov wrote:
>>> Ada.Calendar.Time_Zones might be of use to you. You could store
>>> the value as a string (Ada.Calendar.Formatting).
>>>
>>> See http://www.martin.dowie.btinternet.co.uk/
>>
>> I see a problem with it. UTC_Time_Offset is not constant, so there
>> also should be an atomic way to get exact UTC.
>
> Sorry, not sure what you're getting at here. The UTC_Time_Offset will change
> due to daylight saving, so it can never be a constant.
>
> For Windows, I can't find anything that states if "GetTimeZoneInformation"
> is atomic or not and this is the routine that returns the time structure.
Under Windows I never would use it to get UTC. I would call
QueryPerformanceCounter. Then to convert it to UTC I would use:
[periodically + statistical refinement]
QueryPerformanceCounter 1
GetSystemTimeAsFileTime
QueryPerformanceCounter 2
Mean of 1+2 allows to calculate the offset to UTC epoch. The problem with
using GetSystemTimeAsFileTime alone is that it has a very low resolution,
so one should use some kind of statistical refinement to get closer to
QueryPerformanceCounter accuracy.
> But even if it isn't atomic it's only going to be 'wrong' at most twice a
> year and only for a second or so each time.
Should we shut down the systems for that period of time? (:-)) Then one
cannot deal with past and future times. The time zone itself is not
constant. Governments are very inventive in making our life harder. Time
stamps should be independent on this chaos.
So I am not convinced that Ada.Calendar is a proper place for dealing with
UTC. Time zones are OK there, no question. But similarity between zone
times and UTC is rather apparent. As I said UTC is monotonic, so it should
be Ada.Real_Time.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-06 7:48 0% ` Dmitry A. Kazakov
@ 2004-08-06 9:28 0% ` Martin Dowie
2004-08-06 10:44 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 104+ results
From: Martin Dowie @ 2004-08-06 9:28 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
>> Ada.Calendar.Time_Zones might be of use to you. You could store
>> the value as a string (Ada.Calendar.Formatting).
>>
>> See http://www.martin.dowie.btinternet.co.uk/
>
> I see a problem with it. UTC_Time_Offset is not constant, so there
> also should be an atomic way to get exact UTC.
Sorry, not sure what you're getting at here. The UTC_Time_Offset will change
due to daylight saving, so it can never be a constant.
For Windows, I can't find anything that states if "GetTimeZoneInformation"
is atomic or not and this is the routine that returns the time structure.
But even if it isn't atomic it's only going to be 'wrong' at most twice a
year and only for a second or so each time.
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-05 21:19 6% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
@ 2004-08-06 7:48 0% ` Dmitry A. Kazakov
2004-08-06 9:28 0% ` Martin Dowie
1 sibling, 1 reply; 104+ results
From: Dmitry A. Kazakov @ 2004-08-06 7:48 UTC (permalink / raw)
On Thu, 5 Aug 2004 21:19:07 +0000 (UTC), Martin Dowie wrote:
> Dmitry A. Kazakov wrote:
>>> I need to insert some timestamps (type Ada.Calendar.Time) in a
>>> database accessed via ODBC using gnade+gnat 3.15p.
>>>
>>> I've looked for timestamp support in the gnade sources without much
>>> luck, I've specially checked the embedded sql support and I haven't
>>> found nothing for this purpose.
>>>
>>> I'm completely clueless about the ODBC client packages so if someone
>>> has done this before (with gesql or directly), a quick pointer for
>>> the things to look at would be great.
>>
>> The problem is that Ada.Calendar.Time is a political time, while
>> persistent time stamps should be UTC or any other absolute time. I
>> know no OS-independent solution for that.
Then quite often one need to pass time stamps across partitions distributed
over different time zones. Presently it is very painful.
> Ada.Calendar.Time_Zones might be of use to you. You could store
> the value as a string (Ada.Calendar.Formatting).
>
> See http://www.martin.dowie.btinternet.co.uk/
I see a problem with it. UTC_Time_Offset is not constant, so there also
should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time seems
a better candidate for UTC. I would add it there. Then why not to provide a
numeric type to be a FILETIME equivalent (64-bit value representing the
number of 100-nanosecond intervals since January 1, 1601)? Alternatively
one could define a full-blown UTC_Time type synchronized with
Ada.Real_Time.Time.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-05 21:19 6% ` Martin Dowie
@ 2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
1 sibling, 0 replies; 104+ results
From: Jano @ 2004-08-06 6:31 UTC (permalink / raw)
Martin Dowie dice...
> Dmitry A. Kazakov wrote:
> >> I need to insert some timestamps (type Ada.Calendar.Time) in a
> >> database accessed via ODBC using gnade+gnat 3.15p.
> >>
> >> I've looked for timestamp support in the gnade sources without much
> >> luck, I've specially checked the embedded sql support and I haven't
> >> found nothing for this purpose.
> >>
> >> I'm completely clueless about the ODBC client packages so if someone
> >> has done this before (with gesql or directly), a quick pointer for
> >> the things to look at would be great.
> >
> > The problem is that Ada.Calendar.Time is a political time, while
> > persistent time stamps should be UTC or any other absolute time. I
> > know no OS-independent solution for that.
>
> Ada.Calendar.Time_Zones might be of use to you. You could store
> the value as a string (Ada.Calendar.Formatting).
I hadn't thought of time zones and you both are probably right in your
concern, but for now this is a secondary worry. This is for local and
non-critical use. I simply want to have a timestamp in the database
starting from an Ada time type...
Currently I'm doing something similar to the Martin suggestion: instead
of storing a formatted string, I'm storing the seconds elapsed since an
arbitrary epoch.
This is a bit clumsy since I can't work with dates if I want to keep the
queries indexed. I think I'll move to a two-column-with-trigger-on-
insertion setup if no better solution is found.
Thanks!
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
@ 2004-08-05 21:19 6% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
0 siblings, 2 replies; 104+ results
From: Martin Dowie @ 2004-08-05 21:19 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
>> I need to insert some timestamps (type Ada.Calendar.Time) in a
>> database accessed via ODBC using gnade+gnat 3.15p.
>>
>> I've looked for timestamp support in the gnade sources without much
>> luck, I've specially checked the embedded sql support and I haven't
>> found nothing for this purpose.
>>
>> I'm completely clueless about the ODBC client packages so if someone
>> has done this before (with gesql or directly), a quick pointer for
>> the things to look at would be great.
>
> The problem is that Ada.Calendar.Time is a political time, while
> persistent time stamps should be UTC or any other absolute time. I
> know no OS-independent solution for that.
Ada.Calendar.Time_Zones might be of use to you. You could store
the value as a string (Ada.Calendar.Formatting).
See http://www.martin.dowie.btinternet.co.uk/
Cheers
-- Martin
^ permalink raw reply [relevance 6%]
* Re: Calendar Clock!
[not found] <01bd9987$0ad1d3c0$cfcb60cf@vlcvqqui>
@ 1998-06-17 0:00 7% ` John J Cupak Jr, CCP
0 siblings, 0 replies; 104+ results
From: John J Cupak Jr, CCP @ 1998-06-17 0:00 UTC (permalink / raw)
To: Yanick Hudon
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
Yanick Hudon wrote:
>
> Hi! EveryOne,
>
> I would like to know if there is a way to get the date of the system with
> the package Ada.Calendar like we can do in C???
>
> Can someone give me some information about that???
>
> Thanks in advance!
Well, Yanick, I presume your comment "like we can do in C" means calling
the strftime function defined in <time.h>?
Ada.Calendar does NOT define any formatting for time values. If you want
to format time values, you will have to write your own "time-to-string"
function, or else scrounge up a copy of Wizard Ware's Calendar Utility
package (see "Software Components with Ada", G. Booch). Or, you could
search
the public domain libraries for Ada calendar formatting packages.
Good luck!
--
--------------------------------------------------------------
- John J. Cupak Jr, CCP -
- Raytheon Systems Company - Software Engineering Laboratory -
- tel: 978-858-1222 email (work): jcj@swl.msd.ray.com -
- fax: 978-858-4336 email (home): jcupak@aol.com -
--------------------------------------------------------------
[-- Attachment #2: Card for Cupak Jr, CCP, John J. --]
[-- Type: text/x-vcard, Size: 481 bytes --]
begin: vcard
fn: John J. Cupak Jr, CCP
n: Cupak Jr, CCP;John J.
org: TWK
adr;dom: 50 Apple Hill Road;;MS T3MN35;Tewksbury;MA;01879;
email;internet: jcj@swl.msd.ray.com
title: Senior Software Engineer / Instructor
tel;work: 225-1222
tel;fax: 978-858-4336
tel;home: 603-595-8240
note: EMAIL;AOL:jcupak@aol.com
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard
^ permalink raw reply [relevance 7%]
Results 1-104 of 104 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <01bd9987$0ad1d3c0$cfcb60cf@vlcvqqui>
1998-06-17 0:00 7% ` Calendar Clock! John J Cupak Jr, CCP
2004-08-05 13:44 Inserting Calendar.Time in a database Jano
2004-08-05 15:21 ` Dmitry A. Kazakov
2004-08-05 21:19 6% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
2004-08-06 9:28 0% ` Martin Dowie
2004-08-06 10:44 0% ` Dmitry A. Kazakov
2005-04-21 13:28 Timing Block of GNAT code in milliseconds markp
2005-04-21 18:00 ` tmoran
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-28 20:26 ` Simon Wright
2005-04-29 8:11 ` Dmitry A. Kazakov
2005-04-29 20:52 8% ` Randy Brukardt
2005-04-30 10:02 0% ` Dmitry A. Kazakov
2006-11-23 0:55 Extended 'Succ attribute? Jérémie Lumbroso
2006-11-23 2:04 ` Adam Beneschan
2006-11-24 13:02 7% ` Peter Hermann
2007-06-13 23:19 14% Ada.Calendar.Formatting.Image Jeffrey R. Carter
2007-06-14 5:33 5% ` AW: Ada.Calendar.Formatting.Image Grein, Christoph (Fa. ESG)
2007-06-14 16:53 7% ` tmoran
2007-06-15 4:36 7% ` Jeffrey R. Carter
2007-06-15 5:46 5% ` AW: " Grein, Christoph (Fa. ESG)
2007-06-15 4:37 5% ` Grein, Christoph (Fa. ESG)
2007-06-14 21:49 7% ` Per Sandberg
2007-06-15 4:37 7% ` Jeffrey R. Carter
[not found] <0367891DA5DA7E408D42A860FA002F448D62CA@sma2901.cr.eurocopter.corp>
2007-06-15 8:12 5% ` Grein, Christoph (Fa. ESG)
2007-07-22 21:21 Getting current date and time Maciej Sobczak
2007-07-22 23:00 7% ` Martin
2007-07-23 15:24 0% ` koburtch
2007-07-23 19:57 ` Maciej Sobczak
2007-07-23 20:02 ` Maciej Sobczak
2007-07-23 20:08 ` Maciej Sobczak
2007-07-23 21:43 ` Adam Beneschan
2007-07-24 8:53 ` Maciej Sobczak
2007-07-24 15:24 ` Adam Beneschan
2007-07-25 7:26 7% ` Maciej Sobczak
2007-07-25 7:42 0% ` AW: " Grein, Christoph (Fa. ESG)
2007-10-26 14:58 Real Time IO routines andrew
2007-10-26 17:12 6% ` Ed Falis
2008-04-05 22:51 delay until problem in Windows george.priv
2008-04-07 3:10 6% ` george.priv
2008-04-07 7:25 ` Dmitry A. Kazakov
2008-04-09 14:56 8% ` george.priv
2008-04-24 16:29 13% gnat : "ada.calendar.formatting" is not a predefined library Sébastien
2008-04-24 17:12 7% ` Tero Koskinen
2008-04-25 7:38 7% ` Ludovic Brenta
2008-04-25 7:44 7% ` Sebastien Morand
2008-04-25 8:16 7% ` Ludovic Brenta
2008-04-25 8:47 7% ` Sébastien
2008-04-25 15:43 7% ` Georg Bauhaus
2008-04-25 21:07 7% ` Ludovic Brenta
2008-04-26 8:28 7% ` Georg Bauhaus
2008-04-26 11:53 6% ` Ludovic Brenta
2008-04-27 21:41 7% ` Sebastien Morand
2008-04-25 8:49 7% issing Standard lib in gnat Sébastien
2008-04-25 9:35 6% ` Missing " Ludovic Brenta
2008-05-25 15:22 6% Missing Ada components in Ubuntu Adrian Hoe
2008-05-25 18:29 5% ` Sebastien Morand
2008-05-26 1:28 0% ` Adrian Hoe
2008-08-04 9:31 Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-05 9:10 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-07 2:52 0% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-07 8:27 0% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-07 22:47 ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-08 8:48 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-09 2:09 0% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-09 8:04 0% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-12-09 9:48 Inspiration for a better calendar package? Jacob Sparre Andersen
2008-12-09 10:15 ` Martin
2008-12-09 11:15 ` Dmitry A. Kazakov
2008-12-15 7:45 ` Wilhelm Spickermann
2008-12-15 9:00 5% ` Dmitry A. Kazakov
2008-12-15 12:14 0% ` m.collado
2008-12-15 13:35 0% ` Dmitry A. Kazakov
2009-01-18 21:42 8% Performance of element access in Vector Maciej Sobczak
2009-01-19 0:03 0% ` george.priv
2009-01-19 3:23 6% ` george.priv
2009-01-19 11:25 8% ` Georg Bauhaus
2009-01-20 2:17 ` Randy Brukardt
2009-01-20 23:01 ` Randy Brukardt
2009-01-21 9:15 ` Maciej Sobczak
2009-01-21 18:08 6% ` Georg Bauhaus
2009-01-23 14:55 ` Alex R. Mosteo
2009-01-23 17:30 8% ` Georg Bauhaus
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
2009-03-24 10:55 0% ` reinkor
2009-03-24 12:49 0% ` Martin
2009-03-25 21:55 sjw
2009-03-26 1:38 ` tmoran
2009-03-26 20:58 ` sjw
2009-03-27 12:52 7% ` reinkor
2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 7% ` reinkor
2009-03-30 13:45 9% ` John B. Matthews
2009-03-30 16:52 ` Jeffrey R. Carter
2009-03-30 19:44 8% ` reinkor
2009-09-13 15:36 6% Dates and Times in GNAT on Linux Marc A. Criley
2011-09-16 19:55 13% Ada.Calendar.Formatting bug in GNAT? Maciej Sobczak
2011-09-17 5:59 7% ` Randy Brukardt
2012-07-20 17:18 Ada.Calendar Question awdorrin
2012-07-20 17:59 ` Adam Beneschan
2012-07-20 18:24 7% ` awdorrin
2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo
2012-07-23 22:07 ` Adam Beneschan
2012-07-24 7:24 ` erlo.haugen
2012-07-24 16:26 6% ` Adam Beneschan
2012-07-24 18:28 0% ` Dmitry A. Kazakov
2012-07-24 19:07 7% ` Adam Beneschan
2012-07-24 20:17 0% ` Dmitry A. Kazakov
2014-08-05 19:47 Leap second support and ARM 9.6.1p89/2 Natasha Kerensikova
2014-08-07 4:57 ` Randy Brukardt
2014-08-07 7:35 ` Natasha Kerensikova
2014-08-07 8:59 6% ` Markus Schöpflin
2015-06-21 18:38 Is there an easier way for this? Laurent
2015-06-21 19:15 6% ` Niklas Holsti
2015-06-21 19:41 0% ` Laurent
2015-07-13 13:26 7% Time_Zone-aware Day_of_Week ? Natasha Kerensikova
2015-10-31 20:29 A few questions Laurent
2015-10-31 20:49 5% ` Dmitry A. Kazakov
2015-11-01 13:16 0% ` Laurent
2015-11-02 17:45 7% ` Simon Wright
2016-05-13 20:37 ANN: Introducing AdaBase - Thick database bindings for Ada jrmarino
2016-05-13 21:44 ` Per Sandberg
2016-05-13 23:37 ` Randy Brukardt
2016-05-14 6:59 ` gautier_niouzes
2016-05-16 20:06 5% ` Randy Brukardt
2016-08-17 21:05 GNATCOLL SQLite3 vs Ada.Calendar.Time Stephen Leake
2016-08-18 11:19 ` G.B.
2016-08-18 17:45 ` Stephen Leake
2016-08-18 18:28 ` Jeffrey R. Carter
2016-08-18 19:48 ` Dmitry A. Kazakov
2016-08-18 22:05 5% ` Randy Brukardt
2017-09-16 6:40 NTP Anatoly Chernyshev
2017-09-16 9:29 7% ` NTP Dmitry A. Kazakov
2017-09-18 7:54 ` NTP Tarjei Jensen
2017-09-18 8:21 8% ` NTP Dmitry A. Kazakov
2018-07-17 1:20 How to run a GNAT program without starting a terminal session Jerry
2018-07-17 12:46 ` Björn Lundin
2018-07-17 21:07 ` Jerry
2018-07-17 21:12 ` Shark8
2018-07-17 21:56 ` Jerry
2018-07-18 1:33 7% ` Shark8
2019-04-30 0:58 7% Q: Calendar and time zones b.mcguinness747
2020-03-02 18:49 13% Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves
2020-03-02 23:08 7% ` Randy Brukardt
2020-03-03 12:59 7% ` Marius Amado-Alves
2020-03-03 14:25 5% ` Dmitry A. Kazakov
2020-03-03 14:53 13% ` Simon Wright
2020-03-03 17:40 7% ` Simon Wright
2020-03-03 23:49 5% ` Randy Brukardt
2020-03-04 15:19 7% ` Simon Wright
2020-03-04 22:33 6% ` Optikos
2020-03-05 16:11 6% ` Optikos
2020-03-05 23:29 5% ` Randy Brukardt
2020-03-06 14:42 4% ` Optikos
2020-03-07 0:19 6% ` Randy Brukardt
2020-03-07 1:18 6% ` Optikos
2023-08-18 7:18 Parameterised 'Image Attributes Rod Kay
2023-08-18 8:25 ` Luke A. Guest
2023-08-19 9:14 ` J-P. Rosen
2023-08-19 15:27 4% ` Jeffrey R.Carter
2023-08-20 7:53 0% ` G.B.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox