CVS difference for ais/ai-00351.txt

Differences between 1.15 and version 1.16
Log of other versions for file ais/ai-00351.txt

--- ais/ai-00351.txt	2005/08/05 04:35:29	1.15
+++ ais/ai-00351.txt	2005/10/31 05:18:34	1.16
@@ -4706,6 +4706,350 @@
 
 ****************************************************************
 
+From: Bob Duff
+Sent: Saturday, June 11, 2005  9:55 AM
+
+I hesitate to bring up the subject of "time", but I think these are
+fairly simple, and hopefully will not cause an endless discussion of
+whether George Washington's birthday falls on a Monday in the Julian
+calendar from the point of view of Russia in the year 1895, with leap
+seconds included...  ;-)
+
+----------------
+
+9.6.1:
+
+79/2  procedure Split (Date       : in Time;
+                       Year       : out Year_Number;
+                       Month      : out Month_Number;
+                       Day        : out Day_Number;
+                       Seconds    : out Day_Duration;
+                       Leap_Second: out Boolean;
+                       Time_Zone  : in Time_Zones.Time_Offset := 0);
+
+It seems to me that leap seconds ought to be represented as:
+
+    subtype Leap_Second is Second_Number range 0..1;
+
+rather than Boolean.  That seems more natural -- it's a number of seconds.  And
+folks are going to want to do arithmetic on it.
+
+----------------
+
+83/2  function Value (Date : String;
+                      Time_Zone  : Time_Zones.Time_Offset := 0) return Time;
+
+    84/2  {AI95-00351-01} Returns a Time value for the image given as Date,
+          relative to the given time zone. Constraint_Error is raised if the
+          string is not formatted as described for Image, or the function
+          cannot interpret the given string as a Time value.
+
+I don't know exactly what that means.  I hope there is no implementation
+dependence intended here!
+
+For example, "...24:00:00" and "...10:59:60" and "...10:30:30.00004" can be
+interpreted as Time values (if I write the function that way!).
+
+Maybe it would be clearer to say "...is not a String that would be returned by
+Image for some possible parameter values".  Or just leave out the "or the
+function..." part.  Or add some AARM annotation explaining what's what.
+
+Same issue here:
+
+87/2  function Value (Elapsed_Time : String) return Duration;
+
+    88/2  {AI95-00351-01} Returns a Duration value for the image given as
+          Elapsed_Time. Constraint_Error is raised if the string is not
+          formatted as described for Image, or the function cannot interpret
+          the given string as a Duration value.
+
+----------------
+
+85/2  function Image (Elapsed_Time : Duration;
+                      Include_Time_Fraction : Boolean := False) return String;
+
+    86/2  ...If abs
+          Elapsed_Time represents 100 hours or more, the result is
+          implementation-defined.
+
+This seems like a completely gratuitous incompatibility among implementations.
+Why don't we just say what it does?  "Hour contains at least two digits.  Minute
+and Second contain exactly two digits.  A leading zero is included in each field
+if needed."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2005  10:07 PM
+
+> I hesitate to bring up the subject of "time", but I think these are
+> fairly simple, and hopefully will not cause an endless discussion of
+> whether George Washington's birthday falls on a Monday in the Julian
+> calendar from the point of view of Russia in the year 1895, with leap
+> seconds included...  ;-)
+
+Almost certainly will, I fear.
+
+> ----------------
+>
+> It seems to me that leap seconds ought to be represented as:
+>
+>     subtype Leap_Second is Second_Number range 0..1;
+>
+> rather than Boolean.  That seems more natural -- it's a number of seconds. And
+> folks are going to want to do arithmetic on it.
+
+My initial reaction was yuck. OTOH, my reaction to all of the leap second
+stuff is yuck, so that may not be indicative. Anyway, if anyone out there
+agrees with Bob, please speak up -- else I am just going to ignore this
+comment as too late.
+
+> ----------------
+>
+> 83/2  function Value (Date : String;
+>                       Time_Zone  : Time_Zones.Time_Offset := 0)
+> return Time;
+>
+>     84/2  {AI95-00351-01} Returns a Time value for the image given as Date,
+>           relative to the given time zone. Constraint_Error is raised if the
+>           string is not formatted as described for Image, or the function
+>           cannot interpret the given string as a Time value.
+>
+> I don't know exactly what that means.  I hope there is no implementation
+> dependence intended here!
+
+The intent is exactly as written; De Morgans law applies:
+  (not A) or (not B) = not (A and B)
+That is, the string has to be formatted as described for Image *and* the
+values have to be interpretable as a Time value.
+
+> For example, "...24:00:00" and "...10:59:60" and
+> "...10:30:30.00004" can be
+> interpreted as Time values (if I write the function that way!).
+
+The last one doesn't match the format as specified, so it *has* to raise
+Constraint_Error. The intent is that the first two also raise
+Constraint_Error; it's hard to imagine what time value these would
+correspond to. (And allowing them would violate the meta-rule for Image and
+Value that you can convert back and forth and get the original value.) If
+you try to put the values in your examples above into Time_Of, you'll get a
+Constraint_Error.
+
+> Maybe it would be clearer to say "...is not a String that would be returned by
+> Image for some possible parameter values".  Or just leave out the "or the
+> function..." part.  Or add some AARM annotation explaining what's what.
+
+The former wording brings range issues into the fray (especially an issue
+for the Duration version). I don't think we want to explicitly do that; and
+we'd need a note to tell implementers that we don't really mean that.
+
+Leaving out the "or the function" part would mean that the first two
+examples you gave above would have to be accepted. But what would they mean?
+
+I could imagine more AARM notes on these; but what would they say??
+
+> ----------------
+>
+> 85/2  function Image (Elapsed_Time : Duration;
+>                       Include_Time_Fraction : Boolean := False)
+> return String;
+>
+>     86/2  ...If abs
+>           Elapsed_Time represents 100 hours or more, the result is
+>           implementation-defined.
+>
+> This seems like a completely gratuitous incompatibility among implementations.
+> Why don't we just say what it does?  "Hour contains at least two digits. Minute
+> and Second contain exactly two digits.  A leading zero is included in each field
+> if needed."
+
+Hardly any implementations have a Duration that can represent more than 100
+hours, so the issue doesn't really exist for most. Moreover, we want users
+to be able to depend on the format (exactly 2 digits) for typical time
+values. Four digits is "at least two digits"! And we don't want to make work
+for implementers; exactly 2 digits is a lot easier to implement in Ada than
+"least two digits".
+
+Also, the implementation of this function cannot depend on Split (which only
+works on Day_Duration). We want to limit what implementers have to be able
+to support here, because the calculation can easily overflow and is nowhere
+near as simple to implement as it seems. This working allows implementers to
+raise Constraint_Error if the intermediate calculations overflow, as long as
+they support this up to 100 hours or the range of Duration.
+
+If you insist on exact reproducibility, I'd prefer to have the routine raise
+Constraint_Error if the result doesn't fit in 99 hours. (I'd make a subtype
+of Duration, but that would be out of range on most implementations, and
+using 'Max and 'Min is insane:
+   subtype Image_Duration is Duration range
+Duration'Max(-(100.0*60*60-Duration'Small),Duration'First) ..
+Duration'Min(100.0*60*60-Duration'Small,Duration'Last);
+Yuck!)
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 14, 2005  2:32 AM
+
+> 79/2  procedure Split (Date       : in Time;
+>                        Year       : out Year_Number;
+>                        Month      : out Month_Number;
+>                        Day        : out Day_Number;
+>                        Seconds    : out Day_Duration;
+>                        Leap_Second: out Boolean;
+>                        Time_Zone  : in Time_Zones.Time_Offset := 0);
+>
+> It seems to me that leap seconds ought to be represented as:
+>
+>     subtype Leap_Second is Second_Number range 0..1;
+>
+> rather than Boolean.  That seems more natural -- it's a
+> number of seconds.  And folks are going to want to do
+> arithmetic on it.
+
+In the case of Split, I agree that it is probably more natural (pun?) to
+think of Leap_Seconds as a number.  Unfortunately, the situation is less
+clear for Time_Of, which takes a Leap_Second parameter:
+
+function Time_Of (Year : Year_Number;
+	Month : Month_Number;
+	Day : Day_Number;
+	Seconds : Day_Duration := 0.0;
+	Leap_Second: Boolean := False;
+	Time_Zone : Time_Zones.Time_Offset := 0)
+	return Time;
+
+Here I find it more logical (pun?) to say that we have two times with
+Seconds = 86400, and that they are distinguished by the fact that one is a
+leap second and the other isn't.
+
+Whatever we choose, we should make a consistent decision for all these
+subprograms.
+
+I guess I could go either way, but I don't see a very compelling reason
+for a change.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, June 14, 2005  5:31 AM
+
+Randy Brukardt wrote:
+
+>>    subtype Leap_Second is Second_Number range 0..1;
+>>
+>>rather than Boolean.  That seems more natural -- it's a number of seconds.
+
+I strongly agree
+
+> And
+>
+>>folks are going to want to do arithmetic on it.
+
+yes indeed
+
+> My initial reaction was yuck. OTOH, my reaction to all of the leap second
+> stuff is yuck, so that may not be indicative. Anyway, if anyone out there
+> agrees with Bob, please speak up -- else I am just going to ignore this
+> comment as too late.
+
+the leap second stuff is indeed yuck, but if it is in, might as well
+do it right.
+
+> Hardly any implementations have a Duration that can represent more than 100
+> hours, so the issue doesn't really exist for most. Moreover, we want users
+> to be able to depend on the format (exactly 2 digits) for typical time
+> values. Four digits is "at least two digits"! And we don't want to make work
+> for implementers; exactly 2 digits is a lot easier to implement in Ada than
+> "least two digits".
+
+All implementations of GNAT use a Duration that can represent a lot more
+than 100 hours (a LOT more!)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, June 14, 2005  5:42 AM
+
+Pascal Leroy wrote:
+
+> function Time_Of (Year : Year_Number;
+> 	Month : Month_Number;
+> 	Day : Day_Number;
+> 	Seconds : Day_Duration := 0.0;
+> 	Leap_Second: Boolean := False;
+> 	Time_Zone : Time_Zones.Time_Offset := 0)
+> 	return Time;
+>
+> Here I find it more logical (pun?) to say that we have two times with
+> Seconds = 86400, and that they are distinguished by the fact that one is a
+> leap second and the other isn't.
+
+I disagree, I would find
+
+   Leap_Second : .. := 0;
+
+much more natural here too.
+
+****************************************************************
+
+From: Robert I Eachus
+Sent: Wednesday, June 15, 2005  9:01 PM
+
+Robert Dewar wrote:
+
+> I disagree, I would find
+>
+>   Leap_Second : .. := 0;
+>
+
+Argh!  If you understand what is going on it makes MUCH more sense as a
+boolean.  If you don't understand, then maybe the fact that it is a
+boolean is a clue.   Technically leap seconds work in both directions,
+there can be some 59 second minutes* as well as 61 second minutes.  But
+Ada doesn't have to care--there are just some seconds that no valid
+times will ever convert to.
+
+It is the 61 second minutes that are the problem, and you need to be
+very careful to get this right.  December 31, 2004, Duration = 86400.0
+Leap_Second = False means that this time matches January 1, 2005,
+Duration = 0.0.  Leap_Second = True means that these would be two
+separate times.  What about December 31, 23:59:61?  It is not a valid
+representation of a time, although Year = 1998, Month = 12, Day = 31,
+Duration = 86399.9 Leap_Second = True is a valid representation, and it
+occurs after Year = 1998, Month = 12, Day = 31, Duration = 86400.0
+Leap_Second = True.  Calculations that ignore the Leap_Second parameter
+can be off by a second, but most people won't care.  It is the ordering
+of times where it is important, in other words when you want to know
+which event came first.
+
+*As of right now, it has been over 6 years since a leap second was added
+(December 31, 1998).  The recent earthquake in Indonesia may require
+using a 59 second minute in the near future.  But then again, it may
+not.   The weather, ocean temperature and currents, volcanoes,
+earthquakes, sliding of crustal plates, round the world plane flights,
+and satellite launches can all affect the length of the mean solar day.
+Space shuttle launches affect the rotation rate while the shuttle is in
+orbit, after it lands, any residual effect is due to any satellites
+launched or retrieved.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, June 15, 2005  10:03 PM
+
+> Argh!  If you understand what is going on it makes MUCH more sense as a
+> boolean.  If you don't understand, then maybe the fact that it is a
+> boolean is a clue.   Technically leap seconds work in both directions,
+> there can be some 59 second minutes* as well as 61 second minutes.  But
+> Ada doesn't have to care--there are just some seconds that no valid
+> times will ever convert to.
+
+I read the entire post, and I still disagree, I don't buy the use of
+Boolean here.
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Saturday, July 2, 2005  5:30 PM
 
@@ -4744,4 +5088,3 @@
                   Randy Brukardt, Editor, 8652:AMD.1
 
 ****************************************************************
-

Questions? Ask the ACAA Technical Agent