CVS difference for ai05s/ai05-0119-1.txt
--- ai05s/ai05-0119-1.txt 2010/12/15 00:10:58 1.6
+++ ai05s/ai05-0119-1.txt 2011/02/01 02:52:09 1.7
@@ -1,7 +1,7 @@
-!standard 9.6(24) 08-10-17 AI05-0119-1/00
+!standard 9.6(24/2) 11-01-31 AI05-0119-1/01
!standard 9.6.1(41/2)
!standard 9.6.1(42/2)
-!class Amendment 08-10-17
+!class binding interpretation 11-01-31
!status work item 08-10-17
!status received 08-08-05
!priority Medium
@@ -10,11 +10,14 @@
!summary
-(See proposal.)
+The behavior of Ada.Calendar Time values is not specified in the presence of
+summer time (daylight saving time) adjustments. In particular, the results
+of Ada.Calendar operations on two values obtained with different effective time
+zones is unspecified.
-!problem
+!question
-Ada.Calendar time is not well-defined in the presence of daylight saving time
+Ada.Calendar Time is not well-defined in the presence of daylight saving time
adjustments.
1. Ada.Calendar.Time_Of is ill-defined within the hour when the clock is
@@ -52,16 +55,55 @@
and T2 is CET. These have different offsets to the UTC time, +2h and +1h
correspondingly.
-!proposal
+4. 9.6.1(42) says UTC_Time_Offset "Returns ... the difference between the
+implementation-defined time zone of Calendar, and UTC time". This wording is
+ambiguous as to the sign of the "difference".
-** TBD **
+!recommendation
+(See summary.)
+
!wording
+
+Add after 9.6(24/2):
-** TBD **
+AARM Ramification: The behavior of these values and subprograms if the
+time zone changes is also implementation-defined. In particular, the
+changes associated with summer time adjustments (like Daylight Savings Time
+in the United States) should be treated as a change in the
+implementation-defined time zone. The language does not specify whether
+the time zone information is stored in values of type Time; therefore
+the results of binary operators are unspecified when the operands are
+the two values with different effective time zones. In particular, the
+results of "-" may differ from the "real" result by the difference in the
+time zone adjustment. Similarly, the result of UTC_Time_Offset (see 9.6.1)
+may or may not reflect a time zone adjustment.
+
+Add after 9.6.1(42/2):
+
+AARM Ramification: This is equivalent to subtracting the UTC-time from the
+local-time. In North America, the result be negative; in Europe, the result
+will be zero or positive.
+
+[Editor's note: I was tasked with improving the original wording. But I can't
+see any way to do that without putting more detail into the wording than makes
+sense. The original wording implies an ordering and a sign, it just not crystal
+clear. But I *can* put that detail into an AARM note, and then the intent is
+clear.
+Since we're not making any actual wording changes, perhaps this should be a
+ramification?]
+
!discussion
+Taking the last question first:
+
+The intent is that UTC_Time_Offset means local-time - UTC-time. In the US, this
+value is negative. (This is the same value that you may find in e-mail headers.)
+
+
+For the other questions:
+
[Editor's note: To think about this in the US, use the time November 02, 2008
01:30 AM as the clock will be adjusted at 2:00 AM that day.]
@@ -99,16 +141,60 @@
Calendar.Time (since UTC.Time does not have constructors or splitters),
which would clutter programs.
-There probably are even more approaches necessary. But first we have to decide
-whether to actually fix this problem.
+We have decided to take approach (1), essentially confirming the existing
+standard in that these things are unspecified. Implementations can offer
+additional guarantees if their users so demand.
+
+If we were to require that these operations work without any time zone
+bias in all cases, we would effectively be requiring that the underlying
+implementation by UTC Time plus a time zone indications. (Other implementations
+would have problems at some boundary or other.) Beyond being incompatible with
+many existing implementations, this would be a fairly heavy implementation on
+targets that don't have much time zone support.
+
+We could try to mitigate this problem by somehow defining that systems that
+don't have a concept of time zones are exempt from this requirement. But then
+systems that took advantage of the exemption would still have the original
+problem, and portability would again be reduced. Moreover, it may not help
+in that many embedded apps do know about time zones (my handheld GPSes do, for
+example) but don't provide much support for managing them.
+
+For instance, time zone adjustments on MS-DOS systems back in the day occurred
+when the user adjusted the clock after a time change. Ada programs running at
+that time could have no way of protecting themselves from the change; there would
+be no way of determining the difference between such a time change and the other
+asjustments needed to keep the clock vaguely close to the wall time.
+
+Even on systems with time zone support, there may not be functions to convert
+time values between arbitrary time zones (or even just UTC and local time).
+Older versions of Windows had little such functionality, for instance; if Ada
+required UTC time, an implementation targeting them would have to do much of
+the conversion work to local time itself.
+
+As such, we decided not to add additional requirements.
+
+[Editor's note: One could argue that on modern desktop systems, there isn't
+much reason not to require all times to be stored in UTC and converted on Split.
+One half-measure to accomplish that would be to add Implementation Advice to
+that effect. It still wouldn't be a requirement, so portability would not be
+perfect, but at least the desktop OSes would work right. Of course, that also
+would require breaking of existing binary time values (and quite possibly would
+require time values to be larger). I only suggest this because the above
+arguments seem weak; but I don't have a good idea of how to word an IA, either.]
!example
+(See question.)
!ACATS test
+No additional ACATS tests are needed.
+
+!ASIS
+No change to ASIS is needed.
+
!appendix
From: Dmitry A. Kazakov
@@ -780,27 +866,58 @@
From: Tucker Taft
Date: Thursday, May 20, 2010 6:06 PM
-On our phone call today, we had a somewhat mind-bending discussion of calendar, time zones, and daylight-savings/summer time.
+On our phone call today, we had a somewhat mind-bending discussion of calendar,
+time zones, and daylight-savings/summer time.
We recognized that there are two
distinct strategies for representing
-Calendar.Time, one where the time is kept in UTC internally, and Calendar.Split and Calendar.Time_Of worry about the "local"
-time zone. The other is that Time is represented in local time, and Calendar.Time_Of and Calendar.Split are trivial.
+Calendar.Time, one where the time is kept in UTC internally, and Calendar.Split
+and Calendar.Time_Of worry about the "local" time zone. The other is that Time is
+represented in local time, and Calendar.Time_Of and Calendar.Split are trivial.
Here are some interesting questions:
-
-What does "-"(Time, Time) return for times that cross a daylight/summer timezone change? Clearly if Time is represented internally as UTC time, this is very straightforward.
-If Time is represented as a local time that reflects daylight-savings/summer time, but with no internal bit indicating whether daylight/summer time was in effect when the local time was stored, then it seems clear that "-" will necessarily return a value
of Duration that corresponds to 3600.0 seconds more or 3600.0 seconds less than the actual number of seconds that pass between the two times.
+What does "-"(Time, Time) return for times that cross a daylight/summer timezone
+change? Clearly if Time is represented internally as UTC time, this is very
+straightforward.
+
+If Time is represented as a local time that reflects daylight-savings/summer time,
+but with no internal bit indicating whether daylight/summer time was in effect when
+the local time was stored, then it seems clear that "-" will necessarily return a
+value of Duration that corresponds to 3600.0 seconds more or 3600.0 seconds less
+than the actual number of seconds that pass between the two times.
This seems highly undesirable.
-
-This leads me to suggest that for an implementation that stores local time, during a single execution of an Ada program, all times should use the same time zone, even if daylight/summer time begins or ends during the execution. This also means that UTC_T
ime_Offset should return the same value independent of the Date parameter, reflecting the time zone at the moment when program execution began. This means that Clock will have to undo the effects of any change in daylight savings/summer time since the pro
gram execution began, if the underlying O/S reflects the change immediately. Similarly Split and Time_Of will presume the program-start timezone, even if they represent times when the timezone would be different due to daylight/summer time.
-
-Alternatively, if Calendar.Time is represented as UTC time, then it would be feasible for UTC_Time_Offset to give different values depending on the Date parameter, and for Calendar.Time_Of and Calendar.Split to reflect the different UTC_Time_Offset based
on the Time value represented by the parameters. However, Time_Of would be ambiguous for 2AM-3AM on the day daylight/summer time ends, and the implementation would need to pick one or the other. To be consistent with the implementations using local time,
we would want to specify that when ambiguous, a UTC_Time_Offset is used by Time_Of that corresponds to its value when program execution began.
-
-Of course even more consistent would be to have both implementation approaches always presume the time zone when program execution begins, and have UTC_Time_Offset always return the same value, independent of the Date parameter. However, that seems to fl
y in the face of the description of UTC_Time_Offset.
-The other solution is to effectively require implementations to use UTC time internally, or at least an indication of whether a given "local" time is or is not a daylight/summer time, so that "-", "<", Difference, etc., can properly reflect the true diffe
rence in time. This would then allow UTC_Time_Offset to depend on the Date parameter, as implied by it RM definition.
+This leads me to suggest that for an implementation that stores local time, during
+a single execution of an Ada program, all times should use the same time zone, even
+if daylight/summer time begins or ends during the execution. This also means that
+UTC_Time_Offset should return the same value independent of the Date parameter,
+reflecting the time zone at the moment when program execution began. This means
+that Clock will have to undo the effects of any change in daylight savings/summer
+time since the program execution began, if the underlying O/S reflects the change
+immediately. Similarly Split and Time_Of will presume the program-start timezone,
+even if they represent times when the timezone would be different due to
+daylight/summer time.
+
+Alternatively, if Calendar.Time is represented as UTC time, then it would be feasible
+for UTC_Time_Offset to give different values depending on the Date parameter, and for
+Calendar.Time_Of and Calendar.Split to reflect the different UTC_Time_Offset based on
+the Time value represented by the parameters. However, Time_Of would be ambiguous for
+2AM-3AM on the day daylight/summer time ends, and the implementation would need to pick
+one or the other. To be consistent with the implementations using local time, we would
+want to specify that when ambiguous, a UTC_Time_Offset is used by Time_Of that
+corresponds to its value when program execution began.
+
+Of course even more consistent would be to have both implementation approaches always
+presume the time zone when program execution begins, and have UTC_Time_Offset always
+return the same value, independent of the Date parameter. However, that seems to fly
+in the face of the description of UTC_Time_Offset.
+
+The other solution is to effectively require implementations to use UTC time internally,
+or at least an indication of whether a given "local" time is or is not a daylight/summer
+time, so that "-", "<", Difference, etc., can properly reflect the true difference in
+time. This would then allow UTC_Time_Offset to depend on the Date parameter, as implied
+by it RM definition.
Uggh...
@@ -1177,7 +1294,8 @@
> this AI was considered a "Ramification". Nothing in Ada 95 or Ada 2005
> changed that interpretation. It's not clear that anything *can* change
> that; if the operator manually changes the system time (including when
-> a correction is applied automatically to resync the time with a time-base), most Ada implementations will immediately reflect that change.
+> a correction is applied automatically to resync the time with a time-base),
+> most Ada implementations will immediately reflect that change.
I think that this is an independent issue. The source of clock whether it be
machine's quartz or a user chaotically setting the system time is of no matter
@@ -1323,7 +1441,8 @@
> Saying that changing the time to reflect the time zone manually is
> somehow different than doing it automatically makes no sense.
-Surely it does. The question is the model of clock Ada implementation represents. The mandated one seem to be:
+Surely it does. The question is the model of clock Ada implementation represents.
+The mandated one seem to be:
Ideal-UTC-clock + [noise' +] Political skew + noise -> Ada.Calendar.Time
@@ -1331,7 +1450,10 @@
Ideal-UTC-clock + noise -> Ada.Calendar.Time
-Your argument seems to be that because *some* noise is always added, then it is no matter whether it be just noise or Political skew + noise. That is wrong, because in reality the statistical behavior of the noise and Political skew are greatly different
in all aspects.
+Your argument seems to be that because *some* noise is always added, then it is
+no matter whether it be just noise or Political skew + noise. That is wrong, because
+in reality the statistical behavior of the noise and Political skew are greatly
+different in all aspects.
> Similarly, whether the jumps occur "automatically" or "manually" is
> irrelevant. If your system is connected to a time base via NTP, it
@@ -1339,7 +1461,8 @@
> different (especially in terms of the Standard) than the automatic
> change that occurs when Daylight Savings Time changes? There is no practical difference.
-The practical difference is that NTP adjustments are small and well distributed. Adding the Political skew upon them changes everything.
+The practical difference is that NTP adjustments are small and well distributed. Adding
+the Political skew upon them changes everything.
>> The actual problem is the semantics of how this source is treated
>> within Ada. I see no other way than to treat it as UTC (or
@@ -1413,7 +1536,10 @@
> Sent: Saturday, July 03, 2010 3:28 AM
-Speaking of time issues, your computer is sending messages a day ahead of time. We received this message at about 8:30 UTC on Friday. If we were running Spam Assassin here, we would never have seen it (SA treats messages dated in the future as almost cert
ain spam). I hope you're not using an Ada program for sending mail...
+Speaking of time issues, your computer is sending messages a day ahead of time. We
+received this message at about 8:30 UTC on Friday. If we were running Spam Assassin
+here, we would never have seen it (SA treats messages dated in the future as almost
+certain spam). I hope you're not using an Ada program for sending mail...
> Your argument seems to be that because *some* noise is always added,
> then it is no matter whether it be just noise or Political skew +
@@ -1722,7 +1848,8 @@
> OS, we then "rebase" the clock and return the local time instead. We
> do this so that clock drift, NTP adjustments, manual adjustments, and
> daylight saving time changes are all reflected in the result time.
-> This is important for long running programs - Ada.Calendar needs to reflect the correct (as seen by the computer) time.
+> This is important for long running programs - Ada.Calendar needs to reflect
+> the correct (as seen by the computer) time.
> The net effect of this means that there will be random jumps of at
> least 5 minutes periodically for a long running program. (We do have a
> minimum time between checks for rebasing, in order to improve the
Questions? Ask the ACAA Technical Agent