Ada.Calendar.Formatting.Image (or Time_Of) changing the time

Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Marius Amado-Alves]

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)]

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Randy Brukardt]

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)] 

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Marius Amado-Alves]

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.)

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Dmitry A. Kazakov]

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

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Simon Wright]

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).

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Simon Wright]

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

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Randy Brukardt]

"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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Simon Wright]

"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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Optikos]

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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Optikos]

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

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Randy Brukardt]

"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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Optikos]

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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Randy Brukardt]

"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.

Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time

[Optikos]

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.