experchange > ada

Marius Amado-Alves (03-02-20, 08:49 PM)
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)]
Randy Brukardt (03-03-20, 01:08 AM)
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> wrote in message
news:bce9
[..]
Marius Amado-Alves (03-03-20, 02:59 PM)
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.)
Dmitry A. Kazakov (03-03-20, 04:25 PM)
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.
Simon Wright (03-03-20, 04:53 PM)
Marius Amado-Alves <amado.alves> 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).
Simon Wright (03-03-20, 07:40 PM)
Simon Wright <simon> 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,
Randy Brukardt (03-04-20, 01:49 AM)
"Simon Wright" <simon> wrote in message
news:wfsf
....
> 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.
Simon Wright (03-04-20, 05:19 PM)
"Randy Brukardt" <randy> 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.
Optikos (03-05-20, 12:33 AM)
On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
> "Simon Wright" wrote in message
> news:wfsf
> ...
> 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 ISOstandard 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 theISO/IEC rules.
Optikos (03-05-20, 06:11 PM)
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:
> 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 isa 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.

Randy Brukardt (03-06-20, 01:29 AM)
"Optikos" <ZUERCHER_Andreas> wrote in message
news:cc37
>On Tuesday, March 3, 2020 at 5:49:35 PM UTC-6, Randy Brukardt wrote:
>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.
Optikos (03-06-20, 04:42 PM)
On Thursday, March 5, 2020 at 5:29:35 PM UTC-6, Randy Brukardt wrote:
> Optikos wrote in message
> news:cc37
> 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 anamendment is ISO/IEC-speak. If so-called Ada2020 is fashioned likewise asan 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 AIsthat 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 alsoan 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 andthe Ada 2012 model to be enacted for Ada 2020.

[..]
> 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:202Xto 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.
Randy Brukardt (03-07-20, 02:19 AM)
"Optikos" <ZUERCHER_Andreas> wrote in message
news:7858
....
[..]
>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.
Optikos (03-07-20, 03:18 AM)
On Friday, March 6, 2020 at 6:19:20 PM UTC-6, Randy Brukardt wrote:
[..]
> 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.
Similar Threads