CVS difference for ai05s/ai05-0119-1.txt

--- ai05s/ai05-0119-1.txt	2008/10/25 04:53:14	1.2
+++ ai05s/ai05-0119-1.txt	2009/02/18 05:49:30	1.3
@@ -731,3 +731,48 @@
 is unavailable. On these Time_Offset is considered constant 0.
 
 ****************************************************************
+
+From: Jeffery R. Carter
+Date: Sunday, February 15, 2009  10:03 PM
+
+I have to disagree with the proposal to add political time information to
+Ada.Calendar. It would break a great deal of my company's code because it is
+not backwards compatible.
+
+Ada.Calendar knows nothing of time zones, political time, or daylight savings
+time. This is clear from its definition in the ARM, from Ada 83 through Ada 95
+and on to the current standard. A possible representation of type Time could be
+simply a record of the 4 components. Time_Of checks that the day is legal for
+the year and month, and handles the case of the seconds being Day_Duration'Last,
+but that is all. Split simply returns the 4 components. Whether the resulting
+time is meaningful in any specific political entity is unknown to the package.
+
+Clock returns some "system time", probably external to the language. This system
+time may know about some political entity and jump forward or backward, as the
+ARM specifically allows. In the case where the "system time" jumps backwards,
+Clock may return the same value twice. The meaning of those values is not
+something that Calendar does or can know about.
+
+The new packages added in 9.6.1 know about the system clock's UTC offset, and
+how to convert times from a given offset to and from the system clock's offset,
+but those offsets have no meaning relating to political time. How could they
+when arbitrary offsets with no political meaning may be specified?
+
+For example, the various Time_Of functions treat the time as having the
+specified offset and return the Time value for the time converted to the system
+clock's offset (a time of 12:00:00.00 with Time_Zone => 0 and UTC_Time_Offset
+= -420 [MST, -0700] would give a time of 05:00:00.00). The various Split
+procedures with Time_Zone parameters treat the Date as having the system clock's
+ offset, and return the components of the Date converted to the specified offset.
+
+(Calling the parameter Time_Zone seems a bit misleading, since "time zone" 
+usually refers to a political concept, and the parameter is really an arbitrary
+offset unrelated to any such concept.)
+
+If we want to have operations that know about political time in various political
+entities and their offsets, then we really need to deal with time zones specified
+as strings (since this is a malleable definition and cannot be represented by
+arbitrary numeric values or an enumeration type), such as "US/Mountain" and
+"Europe/Dublin". Clearly such operations do not belong in the existing packages.
+
+****************************************************************