CVS difference for ais/ai-00351.txt

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

--- ais/ai-00351.txt	2003/12/10 00:14:05	1.2
+++ ais/ai-00351.txt	2004/02/04 00:51:13	1.3
@@ -2151,123 +2151,1746 @@
 
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Juanma Barranquero
+Sent: Tuesday, October 21, 2003  5:59 PM
+
+> Unfortunately, ISO-8601 apparently isn't available on the web.
+
+http://lists.ebxml.org/archives/ebxml-core/200104/pdf00005.pdf
+
+> Can anyone quote the part that "defines the week to start on Monday"?
+
+Pg. 4 (from "3. Terms and definitions"):
+
+ "3.28
+  week, calendar
+  time-interval of seven days, starting on a Monday and identified by
+  its ordinal number within a calendar year
+
+  NOTE  A calendar week is often also referred to as week"
+
+Pg. 7:
+
+ "4.3.2.2  The calendar week
+
+  In parallel with the reference system described in 4.3.2.1, there is a
+  reference system based on an unbounded series of contiguos calendar
+  weeks. Each calendar week has seven calendar days as indicated in
+  Table 2.
+
+                     Table 2 -- Calendar days
+
+           Ordinal day                   Calendar day
+          number in the                      name
+               week
+
+                01                          Monday
+                ...                         ..."
+
+Pg. 13:
+
+  "5.2.3  Week date
 
+   [...]
+
+   -- day of the week is represented by one decimal digit. Monday shall
+      be identified as day [1] of any calendar week, and subsequent days
+      of the same week shall be numbered in ascending sequence to Sunday
+      (day [7])."
+
+Pg. 25:
+
+  "Annex A (Informative)
+
+   [...]
+
+   The uniform numbering of weeks necessitates a unique designation of
+   the day on which a week begins. For commercial purposes, i.e.
+   accounting, planning and similar purposes for which a week number might
+   be used, Monday has been found the most appropriate as the first day
+   of the week."
+
+So you could argue that ISO 8601 only defines Monday as the first day of
+the week for "applications", but OTOH, that's the whole point of ISO
+8601, and that's the *only* definition of week to be found on the whole
+document...
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Tuesday, October 21, 2003  8:14 PM
+
+Thanks for the URL.
+
+Having read this, I would contend, in the absence of further guidance
+from the ISO-8601 maintenance committee, that ISO-8601 is silent on
+the definition of week'first outside the narrow context of "week-date"
+formats used for commercial purposes where Monday=1 is appropriate and
+was chosen as the first day of the commercial work week.
+
+I would note in particular that the Scope section, does not list
+standardization of week'first among its eight items, except as a
+subitem to item (c) on week-date formats.
+
+> Pg. 25:
+>
+>   "Annex A (Informative)
+>
+>    [...]
+>
+>    The uniform numbering of weeks necessitates a unique designation of
+>    the day on which a week begins. For commercial purposes, i.e.
+>    accounting, planning and similar purposes for which a week number might
+>    be used, Monday has been found the most appropriate as the first day
+>    of the week."
+
+It seems clear from this paragraph that the definition of week'first would
+not have been included in ISO-8601 at all, except that it was "necessitated"
+by the week-date format, and the considerations of which day to make
+first did not go beyond the commercial work week considerations of the
+intended users of this week-date format.
+
+> So you could argue that ISO 8601 only defines Monday as the first day of
+> the week for "applications", but OTOH, that's the whole point of ISO
+> 8601, and that's the *only* definition of week to be found on the whole
+> document...
 
+I would contend that it's the "*only definition of week to be found on
+the whole document" because ISO-8601 did not see any need to standardize
+the definition of week'first outside the narrow context of week-date formats.
+
+Absent any clear mandate from the ISO-8601 committee, I would contend
+that the ARG should use the most widely accepted definition of week'first,
+so as to avoid criticism as being out of step with customary usage.
+
+I note that existing Ada software uses week'first=Sunday, at least
+as the default, as in:
+
+pragmarc-date_handler.ads:
+    type Day_Name is (Sunday, Monday, Tuesday, Wednesday, Thursday,
+                      Friday, Saturday);
+
+claw-time.ads:
+   type Days_in_Week_Type is (Sunday, Monday, Tuesday, Wednesday, Thursday,
+                              Friday, Saturday);
+
+gtk-calendar.ads:
+  Week_Start_Monday : constant Gtk_Calendar_Display_Options;
+   --  Start the calendar week on Monday, instead of the default Sunday.
+
 ****************************************************************
 
 From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+Sent: Wednesday, October 22, 2003  3:01 AM
+
+> I note that existing Ada software uses week'first=Sunday, at least
+> as the default, as in:
+>
+> pragmarc-date_handler.ads:
+>     type Day_Name is (Sunday, Monday, Tuesday, Wednesday, Thursday,
+>                       Friday, Saturday);
+>
+> claw-time.ads:
+>    type Days_in_Week_Type is (Sunday, Monday, Tuesday,
+> Wednesday, Thursday,
+>                               Friday, Saturday);
+>
+> gtk-calendar.ads:
+>   Week_Start_Monday : constant Gtk_Calendar_Display_Options;
+>    --  Start the calendar week on Monday, instead of the
+> default Sunday.
+
+And the exception that proves the rule:
 
+package GNAT.Calendar is
+
+   type Day_Name is
+     (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003 11:16 AM
+
+Interestingly, GNAT 3.15p seems somewhat conflicted about weekday'first.
+
+a-calend.adb:
+      tm_wday   : int;           -- days since Sunday (0 .. 6)
+
+g-catiio.ads:
+   --          %a   locale's abbreviated weekday name (Sun..Sat)
+   --          %A   locale's    full   weekday   name,    variable   length
+   --                  (Sunday..Saturday)
+   --          %U   week number  of year with  Sunday as first day  of week
+   --                  (00..53)
+   --          %w   day of week (0..6) with 0 corresponding to Sunday
+   --          %W   week number  of year with  Monday as first day  of week
+   --                  (00..53)
+
+g-catiio.adb:
+               when 'T' =>
+               ...
+               --  Locale's abbreviated weekday name (Sun..Sat)
 
+               when 'm' =>
+               ...
+               --  Week number of year with Sunday as first day of week
+               --  (00..53)
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Pascal Obry
+Sent: Wednesday, October 22, 2003 11:28 AM
 
+All your examples are interfaces to OS services. These are defined with Sunday
+being the first day of the Week. As noted the GNAT.Calendar.Day_Name does
+start on Monday and this is a user's API.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003 12:22 PM
 
+I think interfaces to OS services are a signficant consideration, and
+not to be minimized.  These OS services are defined by ISO standards
+(ISO/IEC 9899:1990 and ISO/IEC 9945-1:1996) and are visible in existing
+Ada user API's such as:
+
+windex-time.ads:
+   type Weekday_Type is (Sunday, Monday, Tuesday, Wednesday, Thursday,
+          Friday, Saturday);
+   for Weekday_Type use
+      (Sunday    => 0,
+       Monday    => 1,
+       Tuesday   => 2,
+       Wednesday => 3,
+       Thursday  => 4,
+       Friday    => 5,
+       Saturday  => 6);
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Pascal Obry
+Sent: Wednesday, October 22, 2003  1:43 PM
 
+ > I think interfaces to OS services are a signficant consideration, and
+ > not to be minimized.
+
+Agreed but only if in the spec. The quoted GNAT sources were only
+implementation details.
+
+ > These OS services are defined by ISO standards
+ > (ISO/IEC 9899:1990 and ISO/IEC 9945-1:1996) and are visible in existing
+ > Ada user API's such as:
+ >
+ > windex-time.ads:
+ >    type Weekday_Type is (Sunday, Monday, Tuesday, Wednesday, Thursday,
+ >           Friday, Saturday);
+
+Ok, but you were talking about GNAT. Never we will be able to require all Ada
+libraries to conform to one standard.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003  2:06 PM
+
+Actually, I quoted several from the spec of g-catiio.
+
+#  g-catiio.ads:
+#     --          %a   locale's abbreviated weekday name (Sun..Sat)
+#     --          %A   locale's    full   weekday   name,    variable   length
+#     --                  (Sunday..Saturday)
 
+Rather than being implementation details, these seem to reflect
+common usage of a week running from Sunday to Saturday.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Thomas Wolf
+Sent: Wednesday, October 22, 2003  3:23 AM
+
+Maybe the ARG has already considered this in its last meeting,
+but just in case this was not noted:
+
+The proposed package has
+
+    subtype Hour_Number         is Natural range 0 .. 23;
+    subtype Minute_Number       is Natural range 0 .. 59;
+    subtype Second_Number       is Natural range 0 .. 59;
+    subtype Second_Duration     is Day_Duration range 0.0 .. 1.0;
+
+[...]
+
+    procedure Split (Seconds : in Day_Duration;
+                     Hour : out Hour_Number;
+                     Minute : out Minute_Number;
+                     Second : out Second_Number;
+                     Sub_Second : out Second_Duration);
+
+What is this supposed to return for Seconds = Day_Duration'Last?
+23:59:59 and Sub_Second=1.0? Wouldn't it be more natural to
+define
 
+  type Hour_Number is Natural range 0 .. 24;
+
+and return 24:00:00.00?
+
+When will the revised AI-351 be posted?
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: John Halleck
+Sent: Wednesday, October 22, 2003  9:28 AM
 
+Just to be picky...
+
+What about leap seconds?  Ignoring them has already caused some
+GPS software problems...
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Tucker Taft
+Sent: Wednesday, October 22, 2003  1:15 PM
 
+Not to worry, the ARG spent most of the time relating to
+this AI discussing leap seconds.  This issue will be dealt with
+in the next version of the AI.  (I strongly recommend you all
+hold your comments until you see that one.)
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Jean-Pierre Rosen
+Sent: Wednesday, October 22, 2003  12:25 PM
 
+> Absent any clear mandate from the ISO-8601 committee, I would contend
+> that the ARG should use the most widely accepted definition of week'first,
+> so as to avoid criticism as being out of step with customary usage.
+>
+Could you show evidence that it is actually the "most widely accepted
+definition of week'first"?
+Maybe in the US, but I doubt it if you consider the whole world.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003  4:00 PM
+
+Being from the U.S., I can attest that this is true in the U.S.
+I doubt that the tradition in the U.S. was not imported from Europe.
+
+My understanding is that in many languages, including French, German,
+Spanish, Italian, Romanian, Hebrew, and Arabic, the name for Saturday
+is derived from Sabbath, meaning the 7th day.
+
+My understanding is that the first six days of the week are numbered
+in various languages, such as Hebrew, Arabic, Modern Greek, Portuguese,
+and Vietnamese, starting with Sunday as the first day.
 
+My understanding is that German for Wednesday means mid-week.
+
+My understanding is that some countries such as Russia did not adopt
+the Gregorian calendar (on which Ada.Calendar is based) until relatively
+recently, and may have other traditions.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Alexandre E. Kopilovitch
+Sent: Wednesday, October 22, 2003  4:42 PM
+
+>Being from the U.S., I can attest that this is true in the U.S.
+>I doubt that the tradition in the U.S. was not imported from Europe.
+
+It may be from England, which always was different from continental Europe
+in many respects.
+
+>My understanding is that some countries such as Russia did not adopt
+>the Gregorian calendar (on which Ada.Calendar is based) until relatively
+>recently, and may have other traditions.
+
+I can assure you that in Russia 1st day of week is certainly Monday.
+And I always thought that this is also true in all continental Europe.
 
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Gary E. Barnes
+Sent: Wednesday, October 22, 2003  4:26 PM
+
+ISO-8601, in section 3 "Terms and definitions",
+
+"3.17   week, calendar: A seven day period within a calendar
+year, starting on a Monday and identified by its ordinal number
+within the year; the first calendar week of the years is the one
+that includes the first Thursday of that year.  In the Gregorian
+calendar, this is equivalent to the week which includes
+4 January."
+
+And in section 5 "Representations" in the 2nd paragraph of
+5.2.3 "Date identified by calendar week and day numbers",
+
+"Day of the week is represented by one decimal digit.  Monday
+shall be identified as day [1] of any calendar week, and subse-
+quent days of the same week shall be numbered in ascending
+sequence to Sunday (day [7])."
+
+This would seem to imply that Ada should do something like,
+
+type Day is (Monday, ... Sunday);
+for Day use (Monday => 1, ... Sunday =>7);
+
+Is 8601 ambiguous in some fashion?
 
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003  5:26 PM
+
+> Is 8601 ambiguous in some fashion?
+
+No, its not ambiguous, but it has a very limited scope.
+The scope explicitly involves external representations of dates
+used in communication between mutually agreeable parties.
+
+But that's not what is at issue here.  We are trying to determine if
+8601 should be used as guidance outside its explicit scope, where we
+are concerned with _internal_ representations within an Ada program.
 
+> This would seem to imply that Ada should do something like,
+>
+> type Day is (Monday, ... Sunday);
+> for Day use (Monday => 1, ... Sunday =>7);
+
+That would be silly.  8601 only requires that the external representation
+of Monday=1, and only in the context of week-date formats.  It says nothing
+about internal representations.  (Other ISO standards, of course, do
+say something about internal representations of dates.)
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Juanma Barranquero
+Sent: Wednesday, October 22, 2003  5:37 PM
 
+> My understanding is that in many languages, including French, German,
+> Spanish, Italian, Romanian, Hebrew, and Arabic, the name for Saturday
+> is derived from Sabbath, meaning the 7th day.
+
+Yes, the Spanish name for Saturday is "s bado", obviously derived from
+"sabbath". Still, when spaniards talk about "the next week" they're
+*always* referring to the group of seven contiguous days starting on
+next Monday. And we, as English speakers do, talk about the "fin de
+semana" (the weekend) in reference to Saturday & Sunday.
+
+And finally, the Real Academia Dictionary says about "s bado": "Sixth
+day of the week, seventh of the liturgical week."
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Dan Eilers
+Sent: Wednesday, October 22, 2003  7:27 PM
+
+> And finally, the Real Academia Dictionary says about "s bado": "Sixth
+> day of the week, seventh of the liturgical week."
+
+Interesting.  My Webster's Ninth New Collegiate dictionary says:
+  Saturday:  the seventh day of the week
+  Sabbath: 1a. the seventh day of the week
+
 
+> Yes, the Spanish name for Saturday is "s bado", obviously derived from
+> "sabbath". Still, when spaniards talk about "the next week" they're
+> *always* referring to the group of seven contiguous days starting on
+> next Monday.
+
+Do your calendars start the week with Monday?
+Maybe there is a localization table somewhere that would show
+the local convention for each country in the world.
+
+>               And we, as English speakers do, talk about the "fin de
+> semana" (the weekend) in reference to Saturday & Sunday.
+
+  Weekend:  "The end of the week; specifically, the period between the
+close of one working or business or school week and the beginning of
+the next."
+
+  "weekend" including Sunday doesn't cause us any cognitive difficulties,
+because it is considered to be in relation to the "work week" or
+"school week", not the calendar week.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Randy Brukardt
+Sent: Wednesday, October 22, 2003  8:35 PM
+
+Dan said:
 
+> > Is 8601 ambiguous in some fashion?
+>
+> No, its not ambiguous, but it has a very limited scope.
+> The scope explicitly involves external representations of dates
+> used in communication between mutually agreeable parties.
+>
+> But that's not what is at issue here.  We are trying to determine if
+> 8601 should be used as guidance outside its explicit scope, where we
+> are concerned with _internal_ representations within an Ada program.
+
+This discussion has reached the point of absurdity. The choice of the first
+day of a week is a religious war - there is no logic at all in it. It is the
+problem that caused there to be no day-of-week functions in Ada in the first
+place, and we're heading in that direction again. Which, IMHO, is utterly
+stupid.
+
+Besides, the choice of the first of the Days_of_Week type is pretty much
+irrelevant to the sorts of uses that it intended for. It only matters to
+comparisons, and those are best done with the time values, not with day
+names.
+
+For instance, consider a task that needs to be run every Monday:
+
+    if New_Day and then Day_of_Week (Clock) = Monday then
+         -- Do the task
+    end if;
+
+Or the display of the day of the week in output:
+    type Day_Abbreviations_Type is array (Days_of_Week) of String (1..3);
+    Day_Abbreviations : constant Day_Abbreviations_Type :=
+	   (Sunday => "Sun", Monday => "Mon", Tuesday => "Tue", Wednesday => "Wed",
+          Thursday => "Thu", Friday => "Fri", Saturday => "Sat");
+
+    Put (Day_Abbreviations (Day_of_Week (A_Time));
+
+In neither case does the type definition matter a bit.
+
+I'd probably advocate the "ISO" solution (that is, pick a solution that
+matches no ones position) and start the type with Saturday. Then everyone
+can complain equally. :-)
+
+Thomas Wolf said:
+
+> When will the revised AI-351 be posted?
+
+I don't know, but the more discussion there is, the longer it will be before
+I can work on it. (I have to get completed AIs ready for the upcoming WG9
+meeting before I can work on any open issues. And then I have to file all of
+the mail that has piled up this month.)
+
+*Please* leave the discussion alone until you can read the minutes of the
+October ARG meeting and/or read the revised AI. Otherwise, you're just
+rehashing the already decided.
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Pascal Obry
+Sent: Thursday, October 23, 2003  2:05 AM
+
+ > Actually, I quoted several from the spec of g-catiio.
 
+Right but these are from the second category: Interface. Here is the important
+comment:
+
+   --  This is a string to describe date and time output format. The string is
+   --  a set of standard character and special tag that are replaced by the
+   --  corresponding values. It follows the GNU Date specification. Here are
+   --  the recognized directives :
+
+"GNU Date specification".
+
 ****************************************************************
 
-From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+From: Jean-Pierre Rosen
+Sent: Thursday, October 23, 2003  7:00 AM
+
+> Being from the U.S., I can attest that this is true in the U.S.
+> I doubt that the tradition in the U.S. was not imported from Europe.
+Maybe from the UK...
+
+> My understanding is that in many languages, including French, German,
+> Spanish, Italian, Romanian, Hebrew, and Arabic, the name for Saturday
+> is derived from Sabbath, meaning the 7th day.
+Yes, but this is long forgotten.
+Being from France, I can attest that the first day is Monday, and I guess it
+is the case in most other European countries. Please, readers from other
+countries, tell us about your habits.
+
+Anyway, since this clearly varies between countries, this discussion has
+already occured at ISO level. If the decision of the experts in dates
+processing has been one way, I don't think we have any ground for making a
+different decision.
+
+****************************************************************
+
+From: Ardaud Charlet
+Sent: Thursday, October 23, 2003  7:17 AM
+
+> Yes, but this is long forgotten.
+
+Not really.
+
+> Being from France, I can attest that the first day is Monday, and I guess it
+> is the case in most other European countries. Please, readers from other
+> countries, tell us about your habits.
+
+Just for the sake of completeness, the above is wrong.
+Many people consider that the first day of the week is Sunday in France.
 
+Which does not change the rest of this discussion in any way.
+
+****************************************************************
+
+From: Ehud Lamm
+Sent: Thursday, October 23, 2003  7:14 AM
+
+In Israel the first day of the week is Sunday (it is called "yom rishon"
+which means "first day", by the way).
+The work week these days is usually from Sunday to Thursday.
+
 ****************************************************************
 
+From: Peter Hermann
+Sent: Thursday, October 23, 2003  7:25 AM
+
+> tell us about your habits.
+
+Monday is #1 in all over Europe.
+In Germany I am used to this without exception.
+
+****************************************************************
+
 From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+Sent: Thursday, October 23, 2003  9:06 AM
+
+> > > > > why extend via a child package rather than just adding the
+> > > > > new routines to the existing Ada.Calendar package?
+[snip]
+> Sigh. Anytime you add a "with" or "use", you should expect
+> things to break. But that can only happen in *new* or *modified*
+> code. What we're concerned about is *existing* code that is
+> recompiled with compiler that happens to support Ada 200Y
+> features. This should work, unmodified. That's especially
+> important was we're expecting Ada 200Y to be adopted
+> incrementally, not all at once as Ada 95 was. If someone doesn't
+> use new features, their code should continue to work. (There are
+> a couple of cases where that won't be true, but we believe that
+> they are unlikely to occur in practice. Extra overloadings of
+> "Split" are much more likely to cause trouble.)
+
+Randy,
+
+When you say there are a "couple of cases where that won't be true",
+did you have AI95-00301 (Ada.Strings.Unbounded)) in mind?
+
+If so, then I think this is a *lot* more likely to break existing
+code in practice than adding the additional routines to Ada.Calendar.
+From what I can see in 301 no one has even raised this as an issue.
+
+But I guess YMMV. :-)
+
+****************************************************************
+
+From: Juanma Barranquero
+Sent: Thursday, October 23, 2003 12:52 PM
+
+> Do your calendars start the week with Monday?
+
+Yeah. A calendar with weeks starting on Sunday would look positively
+weird (to us, anyway).
+
+BTW, the system calendar in my Windows XP (Spanish) shows
+monday-starting weeks. It is so in English releases?
+
+>   "weekend" including Sunday doesn't cause us any cognitive difficulties,
+> because it is considered to be in relation to the "work week" or
+> "school week", not the calendar week.
+
+The cognitive disonance is that, for most of us, there aren't two weeks,
+a "work" week and a "calendar" or "religious" week. There are just weeks,
+and they match with what you call "work week".
+
+I'm talking seriously. I know a lot of people with good cultural
+backgrounds who don't even know that the week ever started on Sunday.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Thursday, October 23, 2003  1:49 PM
+
+> BTW, the system calendar in my Windows XP (Spanish) shows
+> monday-starting weeks. It is so in English releases?
+
+No, here the Windows XP calendar (and all the Unix calendars I
+have access to) start the week on Sunday.  I'm sure there is
+a localization file somewhere that gives the country-by-country
+conventions, and it would be very enlightening to see.
 
+> I'm talking seriously. I know a lot of people with good cultural
+> backgrounds who don't even know that the week ever started on Sunday.
+
+Wow.  Do Catholics in Spain still celebrate Easter on Sunday?
+If so, they must wonder why Easter is celebrated on the 7th day of
+the week when well-known passages in Matthew, Mark, Luke, and John
+all place the resurrection "on the first day of the week".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 23, 2003  2:44 PM
+
+Well we have always said that Ada language lawyers are great
+at debating the number of angels that can fit on the head of a pin.
+I think this long-running discussion thread is the closest
+we have come to the literal meaning of this figure of speech.  ;-)
+
 ****************************************************************
 
+From: Juanma Barranquero
+Sent: Thursday, October 23, 2003  2:10 PM
+
+> Wow.  Do Catholics in Spain still celebrate Easter on Sunday?
+
+Sure. Catholics do. According to statistics, like 95% or more of
+spaniards are catholics. In the real world, not a person in ten goes to
+church on a weekly (or even yearly) basis, other than to social acts
+like marriages and the like. Most spanish catholics define themselves
+like "non-practitioner catholics". I'm supposedly catholic and I haven't
+celebrated Easter in my whole life.
+
+And I'd say this is getting off-topic *really* fast :)
+
+****************************************************************
+
+From: Alexandre E. Kopilovitch
+Sent: Thursday, October 23, 2003  7:42 PM
+
+To confuse you even more, I must tell you that Russian name for Sunday (both
+common and official) is exactly "Resurrection" ("Voskresenye" in Russian), and
+Russian Christians are mostly Ortodox Christians. Still Russians think of Sunday
+as of 7th day of week.
+
+I guess than those Christians for whom Sunday is 7th day of week may use quite
+simple logic: as God rested on 7th day of week and we rest on Sunday (note
+that Saturday was not a holiday until relatively recently) then ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 23, 2003 12:02 PM
+
+Martin Dowie said:
+
+> When you say there are a "couple of cases where that won't be true",
+> did you have AI95-00301 (Ada.Strings.Unbounded)) in mind?
+
+No. I was thinking of two AIs having to do with Ada.Exceptions.
+
+> If so, then I think this is a *lot* more likely to break existing
+> code in practice than adding the additional routines to Ada.Calendar.
+> From what I can see in 301 no one has even raised this as an issue.
+
+You must be looking at an old version of 301. There was a lot of discussion
+about compatibility with it, and virtually all of the overloadings that
+would cause trouble have either been removed or renamed. We removed some
+more of them at the most recent meeting. What's left is a few new routines
+with new names and an additional parameter to Index. No overloading that
+might cause problems.
+
+****************************************************************
+
 From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+Sent: Thursday, October 23, 2003  12:20 PM
+
+But the problem (in my eyes!) with the new Ada.Calendar subprograms
+was that they were in a new child package (kludge alert!).
+
+I was shot down for suggesting that the new operations should go in
+Ada.Calendar and I now see in AI-301 that this is exactly what is
+proposed to 'fix' ASU.
+
+Me thinks there is some inconsistency a-foot!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 23, 2003  1:10 PM
+
+The new time operations don't go in Calendar because they don't have much to
+do with the primary purpose of Calendar. The majority of them are for
+human-readable time access, not for any of the core purposes of Calendar
+(providing a time base).
+
+The main problem that I see is the lame name of the child package, and the
+problem there is that really there ought to be several child packages,
+separating time zones, differences, and time formatting. That would make the
+contents more logical and clearly separate from Calendar. Argubly the
+differences stuff belongs in Calendar itself, but I think you'll find
+opposition to that because the new operator symbols would make some existing
+programs illegal. (Adding operators is always dangerous.)
 
 ****************************************************************
 
 From: Martin Dowie
-Sent: Friday, October 17, 2003  2:46 AM
+Sent: Thursday, October 23, 2003  3:32 PM
+
+> The new time operations don't go in Calendar because they don't have much to
+> do with the primary purpose of Calendar. The majority of them are for
+> human-readable time access, not for any of the core purposes of Calendar
+> (providing a time base).
+
+function Day_Of_Week from Time?
+
+Actually, I think this is the one that irked me most... :-)
+
+> The main problem that I see is the lame name of the child package, and the
+> problem there is that really there ought to be several child packages,
+> separating time zones, differences, and time formatting. That would make the
+> contents more logical and clearly separate from Calendar. Argubly the
+> differences stuff belongs in Calendar itself, but I think you'll find
+> opposition to that because the new operator symbols would make some existing
+> programs illegal. (Adding operators is always dangerous.)
+
+Yeah, the name is/was _lousy_ I hope your new AI proposal fits this
+description - sounds much better!
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Thursday, October 23, 2003  7:41 PM
+
+> Being from France, I can attest that the first day is Monday, and I
+> guess it
+> is the case in most other European countries. Please, readers from other
+> countries,
+> tell us about your habits.
+
+European countries use Monday as the first week, including the UK, but
+this is a fairly new convention (measured in decades in countries with
+centuries of history). Back in the good old days, they used Sunday as
+the first day.
+
+In the US, Sunday is still considered the first day, but then we also
+use inches, feet, miles, ounces, pounds, degrees F, and other obsolete
+concepts.
+
+****************************************************************
+
+From: David C. Hoos
+Sent: Friday, October 24, 2003  12:29 PM
+
+For what it's worth, the names of the days of the week in Portuguese
+are Domingo, Segunda-feira, Terca-feira, Quarta-feira, Quinta-feira,
+Sexta-feira, Sabado --.i.e. naming the workdaya in most of the world
+as second-day through sixth-day.
+
+For yet another convention, the imesheets in all of the defense contractors
+for whom I have worked, the pay week is Saturday, Sunday, Monday,
+Tuesday, Wednesday, Thursday, Friday.
+
+****************************************************************
+
+From: Alexandre E. Kopilovitch
+Sent: Friday, October 24, 2003  1:23 PM
+
+Contrary to that, Russian names for days of week clearly indicate that Tuesday
+is second day ("Vtornik"), Thursday is fourth day ("Chetverg") and Friday is
+fifth day ("Pyatnitsa"). [Monday is associated with "per week" ("Ponedelnik"),
+Wednesday - with "middle" ("Sreda"), Saturday is clearly originated from
+Sabbat ("Subbota") and Sunday is exactly "resurrection" ("Voskresenye"). ]
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Thursday, October 30, 2003  3:53 AM
+
+I think "liturgical week" points to the root of the problem.  The liturgical
+week does not have to equal the secular week.  The Church of England has a
+liturgical year that begins at Advent but that doesn't mean that it objects
+to January 1st being commonly referred to as New Year's Day.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, October 31, 2003  2:02 AM
+
+And on a similar vein the UK tax year starts on April 6th.
+It was March 25th (a Qurater Day) more or less in line with
+the ancient Roman calendar I believe.  But when the
+calendars corrected and 12 days were chopped out, the tax
+authorities and taxpayers couldn't face a short year and so
+it got shifted into April.
+
+Well there's an irrelevant piece of infromation.
+
+We need a standard - it doesn't matter too much what it is.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, October 31, 2003  3:15 AM
+
+I suggest we apply YADR (Yet Another Dewar's Rule):
+If it has been decided before, and there is no new element, don't change
+the decision.
+
+People at ISO, who were certainly more knowledgeable on this issue than
+we are, have decided that the week would start on Monday. I don't think
+we have anything new to add since this decision was taken. Moreover, we
+would need *very compelling reasons* to have an ISO standard contradict
+another ISO standard.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, October 31, 2003 11:18 AM
+
+I think it is somewhat unfair to characterize this issue as abiding
+by vs. disregarding a prior ISO decision.  As you know, the prior
+ISO decisions on this issue are in apparent conflict, so it is
+more a question of which ISO decision is more directly relevant
+for Ada's purposes.
+
+The prior ISO standards relating to internal representations of dates
+within software applications, and for communication of dates between
+applications and operating systems services (e.g., ISO C, ISO C++,
+and ISO Posix), use Sunday=0, Saturday=6.  The ISO standard for external
+representation of dates uses Sunday=7, Saturday=6.
+
+I would contend that the interoperability concerns with C, C++, and Posix
+are more relevant for Ada's purposes than the interoperability concerns
+with external date formats.
+
+I would also note that even in Europe, where the convention for the
+starting day of the secular week has shifted relatively recently from
+its historic definition imposed by the Roman Emperor Constantine in
+AD 321 (http://www.cjvlang.com/Dow/main/dow1.html), recent European
+Committee on Standardization documents (e.g., CEN CWA 14051-1 2001,
+http://www.uazone.org/multiling/euroml/euremldocs/cwa14051-1.pdf),
+which are cognizant of ISO 8601, still use the traditional convention
+of listing Sunday first when enumerating the days of the week.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, November 3, 2003  4:42 AM
+
+OTOH, natural Ada usage would imply that you can define subtypes Work_Days and
+Week_Ends, the latter meanint that you need Saturday and Sunday to be adjacent.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, November 3, 2003  5:46 AM
+
+Or maybe we need an AI proposing modular enumeration types...
+
+****************************************************************
+
+From: Peter Hermann
+Sent: Monday, November 3, 2003  5:08 AM
+
+which is most practical for the majority, like in:
+
+International Standard ISO 8601 specifies numeric representations
+of date and time:
+"A week starts with Monday (day 1) and ends with Sunday (day 7)."
+
+I see no need to sacrifice practicality to a religious minority.
+BTW, is NYSE working on sundays?
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, November 3, 2003  2:58 PM
+
+This is of course a completely different argument than your previous
+contention that ISO compliance requires weeks to start on Monday.
+
+Using subranges of enumeration types as poor-man's sets is not generally
+advisable, since a change to the enumeration type (such as would happen
+when switching to a different date package with a different weekday'first)
+will wreak havoc.
+
+There is an example of how to do sets properly in Ada at
+http://www.adapower.com/lang/sets.htm.
+
+
+Peter Hermann wrote:
+> BTW, is NYSE working on sundays?
+
+The NYSE, being a U.S. financial institution, is open for business
+Monday through Friday, and considers Sunday to be first day of the week.
+See http://www.nyse.com/events/1047970075331.html.
+
+****************************************************************
+
+From: David C. Hoos, Sr.
+Sent: Wednesday, November 5, 2003  6:18 AM
+
+> There is an example of how to do sets properly in Ada at
+> http://www.adapower.com/lang/sets.htm.
+
+The correct link is
+ http://www.adapower.com/lang/sets.html.
+
+****************************************************************
+
+From: R. T. Crowley
+Sent: Tuesday, November 11, 2003  2:34 PM
+
+I have been having a rather interesting discussion with Dan Eilers of Irvine
+Compiler Corporation, and he suggested I forward an opinion on the concept of
+"week-date" to you from ISO TC154.  Apparently, there is some question as to
+why the "week-date" numbering and starting point in ISO8601 is different from
+that used in the ISO C, C++, and POSIX standards for representing dates/times
+in binary form.  This discussion apparently began with an email from
+Jean-Pierre Rosen, stating, "People at ISO, who were certainly more
+knowledgeable on this issue than we are, have decided that the week would start
+on Monday.  I don't think we have anything new to add since this decision was
+taken.  Moreover, we would need *very compelling reasons* to have an ISO
+standard contradict another ISO standard."  After some discussion among our
+experts on this we would like to present some further detail.
+
+First, we need to consider the scope of ISO8601.  The standard described in ISO8601 is about representation of dates and times in data interchange when expressed in characters, so it applies to representation on paper, on screen,
+in text based messages (e.g. EDI), and in text based files and databases.  How
+a date is actually represented internally in a (computer) system is not
+ISO8601's business.  Obviously if you have an environment which is text
+oriented (like COBOL) you are well advised to use text representation.
+However, if you work in a "bit oriented environment" you might consider to
+condense something like 2003-11-12 into less bits (if that serves any purpose)
+as long as you do not use it for information interchange.  You could for
+instance convert to Julian date, and store that value as a (bit encoded)
+integer.  In our current terminology we would call that a different time scale.
+However, whereas direct conflicts may in this way be circumvented (in a fairly
+artificial way) and may be mappable; the results of a statement like "the turnover in week X = $...."  in an Ada and an ISO8601 environment become risky
+to compare as they cover different time intervals.
+
+Second, and perhaps more directly to Mr. Rosen's comments about the concept of
+week we should understand there is more in the definition of week then just assigning numbers to days.  ISO8601 is very clear in stating which days
+together form a (calendar) week, showing Saturday and Sunday at the end of the
+week clearly shows why those two days are called the "weekEND" in English.
+Showing weeks beginning on Monday is according to a long standing tradition (therefore a business need) as practiced in Europe and many other parts of the
+world.  If one were to show Sunday to (next) Saturday on one page of an agenda,
+one would not be able to say which week is contained on that page because it
+would contain parts of two weeks.  By showing Monday to Sunday on a page you
+can do this.  Making Sunday the first day of the week will not only change the
+week-number associated with the day, but for some days even the year to which
+the week is assigned.
+
+Third, the choice of numbers applied to each day was questioned during the
+discussion since ISO8601starts by showing the week-date for Monday as a 1, and
+ISO C, C++, and POSIX standards show a week-date for Sunday as a 0.  It is
+apparent the assignment of specific codes was done to indicate a sort order rather than to assign any specific meaning based on the numerals used, in and
+of themselves.  The numbers or codes used could be arbitrarily chosen as any
+numerical, or even alphabetical, sequence, as long as they keep the days of the
+week in proper order according to international custom.
+
+I trust this clarifies the points shown, and indicates the position of ISO
+TC154 on the matter, based upon our interpretation of the standard in ISO8601
+according to the questions raised.  Please feel free to contact me or Louis Visser (louis.visser@nen.nl) on any further questions to do with ISO8601 you
+may have.
+
+          Best Regards,
+               Bob
+
+     R.T.Crowley - Vice Chair, ISO TC154 US TAG
+                         Senior Vice President
+
+     Research Triangle Software, Inc.
+     Suite 200
+     1135 Kildaire Farm Road
+     Cary, NC  27511
+
+     Tel: +1-919-657-0505
+     Cell: +1-919-349-3557
+     Fax: +1-919-657-0589
+     Web: www.rtseducation.com
+              www.ediassistant.com
+              www.cryptobuddy.com
+              www.rtsz.com
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 11, 2003  5:20 PM
+
+R.T. Crowley wrote:
+
+> I have been having a rather interesting discussion with Dan Eilers of Irvine
+> Compiler Corporation, and he suggested I forward an opinion on the concept of
+> "week-date" to you from ISO TC154.
+...
+> First, we need to consider the scope of ISO8601.  The standard
+> described in ISO8601 is about representation of dates and times
+> in data interchange when expressed in characters, so it applies
+> to representation on paper, on screen,
+> in text based messages (e.g. EDI), and in text based files and databases. How
+> a date is actually represented internally in a (computer) system is not
+> ISO8601's business.  Obviously if you have an environment which is text
+> oriented (like COBOL) you are well advised to use text representation.
+> However, if you work in a "bit oriented environment" you might consider to
+> condense something like 2003-11-12 into less bits (if that serves any purpose)
+> as long as you do not use it for information interchange.  You could for
+> instance convert to Julian date, and store that value as a (bit encoded)
+> integer.  In our current terminology we would call that a different time scale.
+> However, whereas direct conflicts may in this way be circumvented (in a fairly
+> artificial way) and may be mappable; the results of a statement
+> like "the turnover in week X = $...."  in an Ada and an ISO8601
+> environment become risky to compare as they cover different time intervals.
+
+This seems to have a bit of a misconception of what we're doing. We're
+working on standardizing a program interface to provide improved
+capabilities for manipulating times. Nothing in the Ada standard says
+anything about binary representations (these are always up to the
+implementation); it only have an effect on how times (and part of times,
+such as the day of the week) are manipulated in program text. Similarly
+(except for one pair of functions which use a subset of the ISO 8601
+representation), nothing in the standard requires any particular text
+representation. We're simply defining a set of operations on times and their
+properties. Any Ada implementation that managed to use a representation
+where a compare or difference gets the "wrong" answer is wrong and ought to
+be fixed. What the standard is about is insuring the definition of the
+"right answer" is clear.
+
+> Second, and perhaps more directly to Mr. Rosen's comments about the concept
+> of week we should understand there is more in the definition of week
+> then just assigning numbers to days.  ISO8601 is very clear in stating which days
+> together form a (calendar) week, showing Saturday and Sunday at the end of the
+> week clearly shows why those two days are called the "weekEND" in English.
+
+As any American 5 year old can tell you, this argument is rubbish. It's
+called the weekend because it is the days at each end of the week (the first
+and last days). (Which doesn't change what ISO 8601 says, of course.)
+
+> Showing weeks beginning on Monday is according to a long standing
+> tradition (therefore a business need) as practiced in Europe and many
+> other parts of the world.  If one were to show Sunday to (next) Saturday
+> on one page of an agenda,
+> one would not be able to say which week is contained on that page because it
+> would contain parts of two weeks.  By showing Monday to Sunday on a page you
+> can do this.  Making Sunday the first day of the week will not only change the
+> week-number associated with the day, but for some days even the year to which
+> the week is assigned.
+
+Of course, this assumes a definition of "week" that does not match that used
+in some significant parts of the world. The long standing tradition in the
+US is precisely to do that (Sunday first, Saturday last which constitutes a
+week), and here you're ignoring the "long-standing business need" for the
+US. (The week-numbering definitions in ISO 8601 are so confusing -
+especially to US-based users - and aren't particularly useful, so we don't
+plan to offer any such capabilities in Ada.)
+
+Anyway, taking off my end-user hat and putting on my ISO standards editor
+hat: It is clear that the ISO 8601 committee did indeed consider these
+issues and make a decision on which day was first. Those that were arguing
+the opposite are simply wrong. (The fact that 8601 got the 'wrong' answer is
+irrelevant. The process of ISO - one country, one vote - pretty much insures
+that the wrong answer will be decided in cases where Europe [many countries]
+differs from the US [one country]. That's just the way it is, folks, and
+that isn't going to change.)
+
+> Third, the choice of numbers applied to each day was questioned during the
+> discussion since ISO8601starts by showing the week-date for Monday as a 1, and
+> ISO C, C++, and POSIX standards show a week-date for Sunday as a 0.  It is
+> apparent the assignment of specific codes was done to indicate a
+> sort order rather than to assign any specific meaning based on the numerals
+> used, in and of themselves.  The numbers or codes used could be arbitrarily
+> chosen as any numerical, or even alphabetical, sequence, as long as they keep
+> the days of the week in proper order according to international custom.
+
+Right. The only substantive difference between the proposals is whether
+Sunday < Monday or whether Sunday > Monday. In practice, this difference
+will hardly ever matter (comparing days of the week is much more likely to
+cause errors than comparing the original time values from which the days of
+the week were extracted in the first place).
+
+It's clear that ISO 8601 says that Sunday > Monday, and therefore (in the
+absence of good arguments to the contrary), Ada should do the same. Given
+that there is very little difference in practice (other than the odd
+definition), it just isn't worth trying to get the 'right' definition.
+(Especially as the only way to do that is to leave it out of the standard.)
+
+(Which I hope brings to a close the 100+ messages on this topic...but I
+doubt it.)
+
+          Randy Brukardt
+          Editor, ISO/IEC JTC1 SC22 WG9 ARG;
+          Editor, ISO/IEC 8652 (Amendment in progress);
+          Editor, AI-351 (the proposal in question), alternatively:
+          Owner, This Hot Potato (as our chairman described it)
+
+****************************************************************
+
+From: Peter Hermann
+Sent: Wednesday, November 12, 2003  6:48 AM
+
+> It's clear that ISO 8601 says that Sunday > Monday, and therefore (in the
+> absence of good arguments to the contrary), Ada should do the same. Given
+
+thank you: I need this for similar practical reasons like for instance
+the overcoming of the arbitrary limit of number_bases (ac00070).
+
+****************************************************************
+
+From: Nick Roberts
+Sent: Saturday, November 15, 2003 11:08 PM
+
+I'd like to make the following comments and preliminary amendment proposal,
+which is based in part on the proposal and comments in AI-351.
+
+If anything I say here contradicts what I've said before, please consider
+this comment to be overriding.
+
+~~~
+
+1. Range of Ada.Calendar.Year_Number
+
+I suggest the range of this subtype is made implementation defined. The
+minimum range 1901..2099 should be imposed at the very least, of course,
+but maybe the minimum should be extended somewhat. Randy suggests
+1600..2400, which I think is probably about right.
+
+I urge that the so-called 'Y2.1K problem' be taken seriously, and dealt
+with as early as possible.
+
+~~~
+
+2. Hours, Minutes, and Seconds
+
+I suggest the following package is introduced:
+
+package Ada.Calendar.HMS is
+
+   subtype Hour_Number      is Natural      range 0 .. 23;
+   subtype Minute_Number    is Natural      range 0 .. 59;
+   subtype Second_Number    is Natural      range 0 .. 59;
+   subtype Second_Duration  is Day_Duration range 0.0 .. 1.0;
+
+   Seconds_Per_Minute : constant := 60.0;
+   Seconds_Per_Hour   : constant := 60 * Seconds_Per_Minute;
+
+   function Hour       (Date : in Time) return Hour_Number;
+   function Minute     (Date : in Time) return Minute_Number;
+   function Second     (Date : in Time) return Second_Number;
+   function Sub_Second (Date : in Time) return Second_Duration;
+
+   function Seconds_Of (Hour       : in Hour_Number;
+                        Minute     : in Minute_Number;
+                        Second     : in Second_Number := 0;
+                        Sub_Second : in Second_Duration := 0.0)
+       return Day_Duration;
+
+   procedure Split (Seconds    : in  Day_Duration;
+                    Hour       : out Hour_Number;
+                    Minute     : out Minute_Number;
+                    Second     : out Second_Number;
+                    Sub_Second : out Second_Duration);
+
+   procedure Split (Date       : in  Time;
+                    Year       : out Year_Number;
+                    Month      : out Month_Number;
+                    Day        : out Day_Number;
+                    Hour       : out Hour_Number;
+                    Minute     : out Minute_Number;
+                    Second     : out Second_Number;
+                    Sub_Second : out Second_Duration);
+
+   function Time_Of (Year       : Year_Number;
+                     Month      : Month_Number;
+                     Day        : Day_Number;
+                     Hour       : Hour_Number;
+                     Minute     : Minute_Number;
+                     Second     : Second_Number := 0;
+                     Sub_Second : Second_Duration := 0.0) return Time;
+
+end Ada.Calendar.HMS;
+
+The named numbers Seconds_Per_Minute and Seconds_Per_Hour are to assist in
+clearly and easily programming computations which involve hours and/or
+minutes.
+
+The meaning of the other declarations in this package are as already
+described in AI-351.
+
+~~~
+
+3. Days and long durations
+
+I suggest the following package is introduced:
+
+with Ada.Calendar.HMS;
+package Ada.Calendar.Diurnal is
+
+   type Long_Duration is delta [imp def] range [imp def];
+
+   type Day_Count is range 0..[imp def];
+
+   Seconds_Per_Day : constant := 24 * HMS.Seconds_Per_Hour;
+
+   function Whole_Days (Interval : Long_Duration) return Day_Count;
+
+   procedure Split (Interval : in  Long_Duration;
+                    Days     : out Day_Count;
+                    Seconds  : out Day_Duration);
+
+   function Duration_Of (Days    : Day_Count;
+                         Seconds : Day_Duration := 0.0)
+         return Long_Duration;
+
+   function "+" (Left : Time; Right : Long_Duration) return Time;
+   function "+" (Left : Long_Duration; Right : Time) return Time;
+   function "-" (Left : Time; Right : Long_Duration) return Time;
+   function "-" (Left, Right : Time) return Long_Duration;
+
+end Ada.Calendar.Diurnal;
+
+The fixed-point type Long_Duration represents a length of time (with no
+specific start or end point), in seconds. The delta and range of this type
+are implementation defined, but I suggest the standard imposes minimum
+requirements, possibly:
+
+   Long_Duration'Delta <= 1.0
+   Long_Duration'First <= -(400 * 365.25 * 86_400)
+   Long_Duration'Last  >= 400 * 365.25 * 86_400
+
+The principle purpose of this type, as the name suggests, is to provide a
+duration type with a much greater range than Standard.Duration, possibly at
+the cost of reduced precision.
+
+The type Day_Count is used by subprograms which manipulate intervals in
+terms of whole days. Its upper bound is implementation defined, but I
+suggest the standard imposes a minimum, for example 146_100 (about 400
+years).
+
+The named number Seconds_Per_Day is to assist the clear and easy
+programming of computations which involve intervals in terms of days.
+
+The usual composition, decomposition, and mixed arithmetic operations are
+provided.
+
+~~~
+
+4. Weeks and days of the week
+
+I suggest the following package is introduced:
+
+with Ada.Calendar.Diurnal;
+package Ada.Calendar.Weeks is
+
+   Seconds_Per_Week : constant := Ada.Calendar.Diurnal.Seconds_Per_Day * 7;
+
+   type Day_Name is
+      (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday);
+
+   function Day_of_Week (Date : Time) return Day_Name;
+
+end Ada.Calendar.Weeks;
+
+I support using the declaration:
+
+   type Day_Name is
+      (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday);
+
+rather than the declaration:
+
+   type Day_Name is
+      (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
+
+since the latter would preclude an encoding that was compatible with the C
+encoding (where Sunday has the code 0, Monday has 1, and so on). It would
+strongly suit at least some implementations to be able to use the C
+encoding.
+
+Within an application, it would be very easy to define a different
+effective ordering of the days, for example by declaring an appropriate
+constant array.
+
+I am sure that the choice between the above two possible declarations of
+Day_Name has no significant impact on the computation of week numbers
+(within the year) conforming to ISO 8601, and has no other consequences as
+regards conformity to ISO 8601 provided an array such as the following were
+used to convert between each day of the week and its corresponding number:
+
+   subtype Day_of_Week_Number is Integer range 1..7;
+
+   DOW_Number: constant array (Day_Name) of Day_of_Week_Number :=
+      (Monday    => 1,
+       Tuesday   => 2,
+       Wednesday => 3,
+       Thursday  => 4,
+       Friday    => 5,
+       Saturday  => 6,
+       Sunday    => 7);
+
+That a standard programming languages declares Sunday first should not be
+interpreted as an assertion as to the correctness of that order of the days
+of the week from a political, trade, industrial, traditional, religious, or
+cultural point of view. It would be a purely technical decision.
+
+~~~
+
+5. Time-related I/O
+
+I suggest the proposed Image and Value functions are dropped, and the
+following I/O packages are provided, which use a format based on ISO 8601,
+with only the simplest formatting options:
+
+with Ada.Calendar, Ada.Text_IO;
+package Ada.Time_Text_IO is
+
+   Default_Aft   : Ada.Text_IO.Field := Day_Duration'Aft;
+   Default_Width : Ada.Text_IO.Field := 20+Default_Aft;
+
+   procedure Get (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Ada.Calendar.Time;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Get (Item  : out Ada.Calendar.Time;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Put (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Ada.Calendar.Time;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Put (Item  : out Ada.Calendar.Time;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Get (From : in  String;
+                  Item : out Ada.Calendar.Time;
+                  Last : out Positive);
+
+   procedure Put (To   : out String;
+                  Item : out Ada.Calendar.Time;
+                  Aft  : in  Ada.Text_IO.Field := Default_Aft);
+
+end Ada.Time_Text_IO;
+
+with Ada.Calendar.Diurnal, Ada.Text_IO;
+generic
+   type Interval_Type is delta <>;
+package Ada.Text_IO.Time_Interval_IO is
+
+   Day_Count_Width : constant := Ada.Calendar.Diurnal.Day_Count'Width;
+
+   Default_Aft   : Ada.Text_IO.Field := Duration'Aft;
+   Default_Width : Ada.Text_IO.Field := 14 + Day_Count_Width + Default_Aft;
+
+   procedure Get (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Interval_Type;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Get (Item  : out Interval_Type;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Put (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Interval_Type;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Put (Item  : out Interval_Type;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Get (From : in  String;
+                  Item : out Interval_Type;
+                  Last : out Positive);
+
+   procedure Put (To   : out String;
+                  Item : out Interval_Type;
+                  Aft  : in  Ada.Text_IO.Field := Default_Aft);
+
+end Ada.Text_IO.Time_Interval_IO;
+
+with Ada.Text_IO;
+generic
+   type Offset_Type is delta <>;
+package Ada.Text_IO.Time_Offset_IO is
+
+   Default_Width : Ada.Text_IO.Field := 6;
+   Default_Aft   : Ada.Text_IO.Field := 0;
+
+   procedure Get (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Offset_Type;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Get (Item  : out Offset_Type;
+                  Width : in  Ada.Text_IO.Field := 0);
+
+   procedure Put (File  : in  Ada.Text_IO.File_Type;
+                  Item  : out Offset_Type;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Put (Item  : out Offset_Type;
+                  Width : in  Ada.Text_IO.Field := Default_Width;
+                  Aft   : in  Ada.Text_IO.Field := Default_Aft);
+
+   procedure Get (From : in  String;
+                  Item : out Offset_Type;
+                  Last : out Positive);
+
+   procedure Put (To   : out String;
+                  Item : out Offset_Type;
+                  Aft  : in  Ada.Text_IO.Field := Default_Aft);
+
+end Ada.Text_IO.Time_Offset_IO;
+
+The general format for the output of values of the type Ada.Calendar.Time
+by the package Ada.Time_Text_IO is:
+
+   YYYY-MM-DDTHH:MM:SS.SSSSSS
+
+where '-', ':', 'T', and '.' are literal, and each numeric field has
+leading zeroes. The number of sub-second digits output is given by Aft; if
+Aft is 0, the decimal separator '.' is not output. Examples are:
+
+   1965-06-28T23:53:12.970
+   2003-11-15T20:55:01.246357
+
+The format expected for input is the same, except that any number of sub-
+second digits are permitted (and the decimal separator may be omitted if
+there are none), and either (but not both together) of the following
+variations are permitted: the '-', 'T', and ':' literals may be omitted;
+each numeric field may have some or all of its leading zeroes omitted.
+
+The general format for the output of values of the type Interval_Type in
+instantiations of the generic package Ada.Text_IO.Time_Interval_IO is:
+
+   PnDTnHnMn.nS
+
+where 'P', 'D', 'T', 'H', 'S', and '.' are literal, and each numeric field
+has no leading zeroes or blanks. The given interval must not be negative
+(Constraint_Error is raised if it is), and will be equal to the number of
+days (the n before the 'D') scaled by the number of seconds per day, plus
+the number of hours (the n before the 'H') and minutes (the n before the
+'M') also appropriately scaled, and seconds (the n.n before the 'S'). The
+number of sub-second digits output is given by Aft; if Aft is 0, the
+decimal separator '.' is not output. Examples are:
+
+   P147DT3H57M46S
+   P0DT0H1M20.000000S
+
+The format expected for input is the same, except that any number of sub-
+second digits are permitted (and the decimal separator may be omitted if
+there are none), and leading zeroes are permitted.
+
+The general format for the output of values of the type Offset_Type in
+instantiations of the generic package Ada.Text_IO.Time_Offset_IO is:
+
+   sHH:MM:SS.SSSSSS
+
+where ':' and '.' are literal, and each numeric field has leading zeroes.
+The initial 's' is a '-' if the given offset is negative, or '+' otherwise.
+The given offset will be equal to the number of hours ('HH') and minutes
+('MM') appropriately scaled, and seconds ('SS'). The number of sub-second
+digits output is given by Aft; if Aft is 0, the decimal separator '.' is
+not output. If the magnitude is not less than 24 hours, the exception
+Constraint_Error is raised. Examples are:
+
+   +01:00:00
+   -00:03:52.013
+
+The format expected for input is the same, except that any number of sub-
+second digits are permitted (and the decimal separator may be omitted if
+there are none), and either (but not both together) of the following
+variations are permitted: the ':' literals may be omitted; each numeric
+field may have some or all of its leading zeroes omitted.
+
+For all three packages, a maximum width is given in the parameter Width or
+in the case of output into a string it is taken to be the width of the
+string. If the value 0 is passed for the Width parameter, then there is no
+maximum width. If the maximum width is insufficient (for all the output to
+fit), the seconds, the preceding separator ':' or following separator 'S',
+and any decimal separator '.' and sub-seconds are not output. If the
+maximum width is still insufficient, then the minutes, the preceding
+separator ':' or following separator 'M' are not output. Except for
+instantiations of Ada.Text_IO.Time_Offset_IO, if the maximum width is still
+insufficient, then the hours, the preceding separator 'T' and following
+separator 'H' if any are not output. If the maximum width is still
+insufficient, the exception Ada.IO_Exceptions.Layout_Error is raised (and
+nothing is output).
+
+The advantage of using a purely numeric format whose components are in
+strictly descending order of significance (from left to right) in all of
+these packages is that textual sorting will always work: times will be
+sorted in correct chronological order; intervals will be sorted in correct
+magnitude order; offsets will be sorted according to magnitude grouped by
+negative and positive values.
+
+The advantage of having no spaces in any one time, interval, or offset is
+that spaces are used as delimiters between numeric (and enumeration
+literal) values in Ada, and it might be valuable to be able to use spaces
+as delimiters between those and time-related values.
+
+The specific advantage of outputting time-related values using ISO 8601
+formats is to reduce the danger of misinterpretation or the failure of
+interpretation by a human (for example by someone not familiar with a
+particular non-standard format or a particular language's name for a day or
+month) or by software.
+
+I think it is getting into muddy waters trying to cater for too many other
+formats, and unnecessary. Within an application, more complicated formats
+are easily output by instantiating inner packages of Ada.Text_IO for
+subtypes declared in Ada.Calendar (and its children), possibly together
+with constant arrays for day or month names. I don't think it would be
+appropriate to provide these facilities in the (primary) language standard,
+since applications' requirements tend to be too complex and inidividual.
+
+~~~
+
+6. Conversion between local and universal time
+
+In general there will be certain local times (as returned by
+Ada.Calendar.Clock) which correspond to more than one UTC time, and vice
+versa. This is certainly the case for localities which have daylight saving
+time at certain times of the year, but it is a situation that could be
+caused by the local time changing for any reason (for example, because the
+computer was moved). At the miniscule level, another cause of this problem
+will be the occasional adjustments made to UTC (the addition or subtraction
+of a leap second).
+
+If the local time can change -- and I think we have to assume that in
+general it can -- then either the implementation must get these
+calculations wrong, or it must store an indication of the current time zone
+(or associated offset from UTC) in the type Time. I suspect the latter
+option was not intended, being an unacceptable distributed overhead. The
+former option might be considered acceptable, but I just like to point out
+the potential problems.
+
+[Incidentally, would the term 'bloat' be a good replacement for the
+cumbersome 'distributed overhead'? In fact, isn't the term 'distributed
+overhead' itself an example of terminological bloat? :-]
+
+I suggest that if a universal time facility is going to be provided by the
+language standard, it should be in a separate package, in a separate
+optional annex:
+
+package Ada.Calendar.Zones is
+
+   type Universal_Time is delta [imp def] range [imp def]; -- MJD/UTC
+
+   subtype Local_Time_Offset is Duration range -39_600.0 .. +46_800.0;
+
+   function "+" (Left  : Universal_Time;
+                 Right : Local_Time_Offset) return Universal_Time;
+
+   function "+" (Left  : Local_Time_Offset;
+                 Right : Universal_Time) return Universal_Time;
+
+   function "-" (Left  : Universal_Time;
+                 Right : Local_Time_Offset) return Universal_Time;
+
+   function "-" (Left  : Universal_Time;
+                 Right : Universal_Time) return Local_Time_Offset;
+
+   procedure Read_Clock (Date   : out Time;
+                         Offset : out Local_Time_Offset);
+
+   procedure Read_Clock (Date      : out Time;
+                         Offset    : out Local_Time_Offset;
+                         Zone_Name : out String;
+                         Zone_Last : out Natural);
+
+   function To_Local (Date   : in Universal_Time;
+                      Offset : in Local_Time_Offset := 0.0) return Time;
+
+   function To_Universal (Date   : in Time;
+                          Offset : in Local_Time_Offset := 0.0)
+         return Universal_Time;
+
+   function Zone_Offset return Local_Time_Offset;
+
+   function Zone_Name return String;
+
+   procedure Set_Zone (Offset : in Local_Time_Offset;
+                       Name   : in String := "");
+
+end Ada.Calendar.Zones;
+
+The type Universal_Time is a (visibly) fixed point type that expresses a
+point in universal time in terms of Modified Julian Days (MJD) aligned with
+UTC (MJD/UTC). For more about MJD please see:
+
+   http://tycho.usno.navy.mil/mjd.html
+
+Note that MJD/UTC is specifically directly related to Coordinated Universal
+Time (UTC), so that there is a direct and unambiguous mapping between them.
+MJD/UTC can be considered a representation of UTC.
+
+The standard should impose appropriate minimum requirements on the delta
+and range of Universal_Time, possibly:
+
+   Universal_Time'Delta <= 86_400 * Duration'Delta
+
+   Universal_Time'First <=
+      To_Universal( Time_of(Year_Number'First,1,1,0.0) )
+
+   Universal_Time'Last >=
+      To_Universal( Time_of(Year_Number'Last,12,31,86_400.0) )
+
+Since the type Universal_Time is scalar, it should provide a very
+convenient means of performing linear temporal calculations.
+
+The subtype Local_Time_Offset represents the difference between local time
+and UTC, in seconds, ranging from half a day behind to half a day ahead
+with an extra hour leeway at both ends (to accommodate daylight saving
+time). The polarity of offset values accords with ISO 8601:
+
+   local time = universal time + offset
+
+The usual mixed arithmetic operations between Universal_Time and
+Local_Time_Offset are provided.
+
+The To_Local function converts from universal time (MJD) to the Time type,
+adjusted for the given Offset. [The given Offset will be added to the given
+Date before the conversion to a Time value.]
+
+The To_Universal function converts from the Time type to universal time
+(MJD), adjusted for the given Offset. [The given Offset will be subtracted
+from the given Date before the conversion to a Universal_Time value.]
+
+The Read_Clock procedures provide the same functionality as the Clock
+function, but they also supply the difference between the time system of
+the clock and UTC. The second overloading also supplies the name of the
+clock's time zone, if known; the value is put into the first n characters
+of Zone_Name, where n is the length of the name, and n-Zone_Name'First+1 is
+put into Zone_Last; if the zone name is unavailable for any reason, n=0.
+
+The Zone_Offset and Zone_Name functions return the clock's current offset
+and zone name (or "" if none). These values may be prone to external
+modification at any moment.
+
+The Set_Zone procedure makes it possible to change the (apparent or
+effective) offset and zone name of the system clock. This procedure is
+likely to be subject to privilege verification on many systems. It is
+implementation defined whether the modifications made by this procedure
+propagate to other programs executing in parallel with or after the calling
+program.
+
+If Set_Zone is refused permission, it should raise some appropriate
+exception. Otherwise, if any of the subprograms fails, it should raise
+Time_Error.
+
+I think the advantages of the above package over the proposal in the AI
+are:
+
+(a) the Time type is not burdened with anything relating to conversions
+between local and universal time;
+
+(b) the Ada.Calendar.Zones package provides the basis for the addition of
+much more sophisticated time zone functionality (that it would be
+inappropriate to provide in the language standard itself);
+
+(c) the package is optional, so it can be completely ignored by
+implementations for which it would be inappropriate (somewhat better, I
+think, than the implementation having to provide dummy bodies which always
+raise an exception).
+
+~~~
+
+Note that I've spent quite a bit of time (a few days) on this comment,
+revising it several times, so I hope that it is now in a reasonably
+sensible and useful form. However, I must admit, this also suggests that it
+probably still contains faults, so some eagle eyes (and minds) may be in
+order when appraising it.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent