* Ada.Calendar.Formatting.Image (or Time_Of) changing the time @ 2020-03-02 18:49 Marius Amado-Alves 2020-03-02 23:08 ` Randy Brukardt 2020-03-03 14:53 ` Simon Wright 0 siblings, 2 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-02 18:49 Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves @ 2020-03-02 23:08 ` Randy Brukardt 2020-03-03 12:59 ` Marius Amado-Alves 2020-03-03 14:53 ` Simon Wright 1 sibling, 1 reply; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-02 23:08 ` Randy Brukardt @ 2020-03-03 12:59 ` Marius Amado-Alves 2020-03-03 14:25 ` Dmitry A. Kazakov 0 siblings, 1 reply; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-03 12:59 ` Marius Amado-Alves @ 2020-03-03 14:25 ` Dmitry A. Kazakov 0 siblings, 0 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-02 18:49 Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves 2020-03-02 23:08 ` Randy Brukardt @ 2020-03-03 14:53 ` Simon Wright 2020-03-03 17:40 ` Simon Wright 2020-03-03 23:49 ` Randy Brukardt 1 sibling, 2 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-03 14:53 ` Simon Wright @ 2020-03-03 17:40 ` Simon Wright 2020-03-03 23:49 ` Randy Brukardt 1 sibling, 0 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-03 14:53 ` Simon Wright 2020-03-03 17:40 ` Simon Wright @ 2020-03-03 23:49 ` Randy Brukardt 2020-03-04 15:19 ` Simon Wright 2020-03-04 22:33 ` Optikos 1 sibling, 2 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-03 23:49 ` Randy Brukardt @ 2020-03-04 15:19 ` Simon Wright 2020-03-04 22:33 ` Optikos 1 sibling, 0 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-03 23:49 ` Randy Brukardt 2020-03-04 15:19 ` Simon Wright @ 2020-03-04 22:33 ` Optikos 2020-03-05 16:11 ` Optikos 2020-03-05 23:29 ` Randy Brukardt 1 sibling, 2 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-04 22:33 ` Optikos @ 2020-03-05 16:11 ` Optikos 2020-03-05 23:29 ` Randy Brukardt 1 sibling, 0 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-04 22:33 ` Optikos 2020-03-05 16:11 ` Optikos @ 2020-03-05 23:29 ` Randy Brukardt 2020-03-06 14:42 ` Optikos 1 sibling, 1 reply; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-05 23:29 ` Randy Brukardt @ 2020-03-06 14:42 ` Optikos 2020-03-07 0:19 ` Randy Brukardt 0 siblings, 1 reply; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-06 14:42 ` Optikos @ 2020-03-07 0:19 ` Randy Brukardt 2020-03-07 1:18 ` Optikos 0 siblings, 1 reply; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time 2020-03-07 0:19 ` Randy Brukardt @ 2020-03-07 1:18 ` Optikos 0 siblings, 0 replies; 14+ messages in thread 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 [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-07 1:18 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-02 18:49 Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves 2020-03-02 23:08 ` Randy Brukardt 2020-03-03 12:59 ` Marius Amado-Alves 2020-03-03 14:25 ` Dmitry A. Kazakov 2020-03-03 14:53 ` Simon Wright 2020-03-03 17:40 ` Simon Wright 2020-03-03 23:49 ` Randy Brukardt 2020-03-04 15:19 ` Simon Wright 2020-03-04 22:33 ` Optikos 2020-03-05 16:11 ` Optikos 2020-03-05 23:29 ` Randy Brukardt 2020-03-06 14:42 ` Optikos 2020-03-07 0:19 ` Randy Brukardt 2020-03-07 1:18 ` Optikos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox