draft-newman-datetime-01.txt

Paul Eggert eggert at twinsun.com
Thu Jan 30 03:11:50 UTC 1997


I agree with most of Markus Kuhn's comments and have the following
further comments and suggestions.


* I agree with Markus that ambiguous local times are a problem, but
the proposed A/B notation is not an adequate solution.  That notation
works in the European context, where the rules are simple and uniform,
but it won't work well in general and it's painful to implement reliably.
Here are some problems with it:

   - The A/B notation is relatively easy to implement in the simple
     case of moving the clocks back in autumn with predefined time
     zone rules; but it's harder to implement when the clocks are
     moving back due to a change in the standard UTC offset, or if the
     clocks are changing from double-DST to single-DST, or if both UTC
     offset and DST change simultaneously, or if the rules change
     before the time in question.  All of these problems have
     occurred in practice.  I doubt whether it's possible to write
     ISO C code that does the job in the general case, for both
     generating and scanning the proposed A/B format.

   - The A/B notation collides with other longstanding notations.

     . In the military tradition, `A' and `B' stand for
       +0100 and +0200, respectively.  This is particularly confusing
       since the proposed standard already uses `Z' in the military sense,
       and the military A/B/Z notation is used in RFC 822.

     . In the US, at least, `A' is a common abbreviation for `A.M.'
       (`A' is used in airline tickets, for example).

     These problems can be fixed by using non-letters instead of `A' and `B'.

   - The A/B notation raises other questions.  For example, are A and B allowed
     with local times that are _not_ ambiguous, and if so, how are they
     interpreted?  What if an ambiguous time is seen without the A/B
     notation?

Here's a counterproposal that avoids the above problems.  Instead of
having a special A/B notation for ambiguous local times, simply
have section 6.7 require the UTC offset.  That is, instead of

	1996-10-27T02:30:00A Europe/Paris [+02:00]
	1996-10-27T02:30:00B Europe/Paris [+01:00]

(where the bracketed items are optional), require the UTC offset instead:

	1996-10-27T02:30:00 Europe/Paris +02:00
	1996-10-27T02:30:00 Europe/Paris +01:00

This counterproposal simplifies the notation and removes options,
which is a stated goal of the draft.


* In practice the choice of time zone rule names may be controversial.
To encourage standardization and head off as much controversy as possible,
I'd like to echo Markus's suggestion to add (to the draft's section 6.3)
as much as possible from the advice to submitters of new time zone
rule names, taken from the `africa' file of the
<URL:ftp://elsie.nci.nih.gov/pub/> registry.

The only problem I see here is that section 6.3 of the draft
recommends hyphen over underscore for future names, which disagrees
with current practice.  The current database contains just 3 names
with hyphen, as opposed to 44 names with underscore, so the
recommendation in 6.3 to avoid underscore would lead to confusing
inconsistencies as new names are added.  Also, in the current tz
database, hyphen represents itself (e.g. "Port-au-Prince") and
underscore represents space (e.g. "New_York"), so the recommendation
in 6.3 to avoid underscore would cause minor loss of information.  In
practice, underscore should not be a problem, as software can
transliterate it to a space before display if underscore has
undesirable behavior in a particular application.


* The draft uses "T" as a date/time separator.  We've written about
this in scattered email messages and I'd like to summarize the
argument against.  I continue to believe that using "T" is unwise for
dates meant for human consumption, as "T" makes dates hard to read.

I have some experience with this: I tried using "T" in a popular
application that requires human-readable dates (the Revision Control
System <URL:ftp://prep.ai.mit.edu/pub/gnu/rcs-5.7.tar.gz>), and the
result was so unreadable that I switched to " ".  I believe that ISO
8601 allows " ", since the "T" is optional and white space is allowed,
and I've seen examples of white space in an official UN document that
recommends the numerical representation of dates and time (see
<URL:http://www.unicc.org/unece/trade/rec/rec07en.htm>).
Unfortunately, I don't have a copy of ISO 8601 to quote chapter and
verse on this.  I hope that someone else with access to ISO 8601 can comment.


* Here are some other comments, keyed by section number in the draft.

1.  This section should somehow state that only nonnegative Gregorian
years are allowed, i.e. the document's scope does not cover B.C.E. dates.
(The year 0 is allowed, which is fine by me, but is this intentional?)

2.  Another good reference for time scales and measurements is Terry
J. Quinn, The BIPM and the Accurate Measurement of Time, Proc. IEEE,
vol. 79, no. 7 (1991-07), 894-905.  For example, it reports that the
Bureau International de l'Heure has been dissolved.

3.  (``If a two digit year is received'') The text makes it sound like
this is the normal turn of affairs.  Please make it clearer that
two digit years can be received only from a sender that does not conform
to the protocol.

``MUST'' is too strong here, since the draft is talking about how a
host should handle text that does not conform to the protocol.  At
best this section should say ``should'' instead of ``MUST''.

The last subsection says programs ``should detect''; reword this to
``may detect'' for consistency with the second subsection.

The last subsection (about dates like `:0-12-31') is a bit bizarre.
(Will the draft eventually include similar recommendations for EBCDIC?
After all, mainframes have the most problems with 4-digit years....)
I would remove it.

4.2.  Mention here that when the local offset changes, the convention
is that instant of change has the new offset, not the old.  For
example, the most recent transition in Los Angeles was from
1996-10-27T01:59:59-07:00 to 1996-10-27T01:00:00-08:00, and
1996-10-27T02:00:00-07:00 is not a valid local time stamp in Los Angeles.
This matches current practice.

4.3.  The difference between +00:00, -00:00, and Z is not explained well.
I would add words to the following effect.

	The time-offsets "+00:00", "-00:00", and "Z" all specify UTC
	but they have different semantic interpretations, as follows:

		"+00:00" means local time is equal to UTC.
		"-00:00" means local time is unknown.
		"Z"      means local time is irrelevant.

However, I don't see the need for "-00:00"; "Z" suffices for both
unknown and irrelevant local times.  I would remove "-00:00".

5.6.  The text doesn't say whether white space is allowed; in many
RFCs white space is allowed between tokens so this point should be
clarified.

5.7.  This section has some confusions about leap seconds.

  * `:60' is not conforming at the end of any June or December, only
	in Junes and Decembers where leap seconds are actually inserted.
  * Leap seconds can be deleted as well as inserted, though this
	has never occurred in practice.  So in theory, `:59' should not
	conform at the end of any June or December where a leap second has
	been deleted.
  * This section assumes that an inserted leap second must be 23:59:60.
	But it can have some other value in local time.  For example,
	using the format of section 6.7 the most recent leap second was

		1995-12-31T15:59:60 America/Los_Angeles -08:00

	using Los Angeles time.

The draft should cover interoperability problems between hosts that
support leap seconds and hosts that do not support leap seconds.
(For example, the POSIX.1 time interface explicitly disallows leap seconds.)
I suggest adding text along the following lines to this part of the draft:

	Hosts should accept all partial-times ending in `:59:59' and
	`:59:60', regardless of whether the times are actually conforming,
	to encourage interoperability between hosts that support leap
	seconds and hosts that do not.

The draft should cover problem of truncating versus rounding time stamps.
I suggest adding text along the following lines.  (Markus also mentioned
this.)

	When generating time stamps, hosts should truncate times
	instead of rounding them.  For example, if the time is
	12:34:56.789, a host should generate "12:34:56" instead of
	"12:34:57".

5.8.  The examples should mention "+00:00" and "-00:00" as well as "Z",
particularly if "-00:00" continues to have special semantics.

6.3.  No current implementations that I know of support
case-insensitive matching for time zone rule names; they are all
case-sensitive.  This requirement is unnecessary and should be removed
(or at least should be changed from MUST to SHOULD).

A minor point: the registry at <URL:ftp://elsie.nci.nih.gov/pub/> is
constrained to use names that are not allowed as TZ strings by
POSIX.1; this is so that it does not conflict with POSIX.1.  If the
name starts with a continent or ocean name as shown in 6.6, no
conflict is possible.

6.4.  I suggest that IANA coordinate with tz at elsie.nci.nih.gov on time
zone rule name registry.  I suggest that XXX be `elsie.nci.nih.gov',
but you'll need help with ado at elsie.nci.nih.gov to set this up.

6.5.  I'll volunteer to review time zone rule names, if that helps.

6.7.  I agree with Markus that it's odd to put the zone-name smack in
the middle of the ISO 8601 time stamp; it'd be better to put it after.
This is more consistent and will make it easier to write date parsers.

Also, why is this format constrained to future dates?
Please explain why this constraint is needed.

   - I don't see how the future-date constraint is enforceable.
   There may be some delay between sending the time stamp and receiving
   it, and in that delay the time stamp may become a past date, so the
   receiver must be able to handle this format for past dates anyway.

   - This format might be useful for past dates in their own right.
   For past events some time stamps may be known accurately in local
   time, but the time zone rules may be as-yet-unknown or disputed; an
   example of this would be the poll-closure times for regional elections
   in Argentina in the early 1990s, a time when that country was
   squabbling over daylight-saving rules and it's not clear that the
   current tz database matches the local times actually in effect.


* Here are some minor points that clearly need patching.  The end of
this message contains a `diff' listing covering suggestions for all
these points.

Minor points overall:

Sometimes the document says ``timezone''; other times ``time zone''.
Standardize on the latter, for consistency with most dictionaries.
Similarly, dictionaries prefer ``daylight-saving time'' to ``daylight
savings time'', so standardize on that.

The document sometimes breaks lines improperly (e.g. `1996-12-
20T00:39:57Z').

Minor points by section:

2.  The Bureau International de l'Heure has been dissolved.  UTC is
now under control of the BIPM and the IERS.

Some minutes are 59 or 61 seconds long, due to leap seconds.

3.  Traditionally ``21st century'' means 2001-2100, but the draft uses
``century'' to mean 2000-2099.  Reword to avoid confusion.  Similarly
for ``decade''.  (This rewording is also needed in section 6.8 and
Appendix A.)

4.2.  The example at the end of the section is off by 8 minutes.

5.8.  Use a decimal fraction that exceeds .59 in an example, to make
it clear that fractions are decimal, not sexagesimal.

6.2 (and other sections).  Use <URL:...> syntax as per RFC 1738.

6.8.  1999-12-31T23:59:59 will be the last second of 1999 in New York
even if a leap second is inserted at the end of December 1999, since
leap seconds are inserted using UTC, not local time.  Similarly for
Adelaide.  (Markus also mentioned this.)

The most likely UTC offset for Adelaide in summer 2000/2001 is +10:30,
not +09:30.

Point of information: the EU daylight-saving rules switch at 01:00
UTC, which makes it quite unlikely for the US to adopt them unchanged.

B.  The code uses the word `cent' without declaring it.  It should
also avoid the term ``century'' to minimize the confusion mentioned
above.

Other misspellings/miswordings: consistancy, semanticly, redunant,
conformant -> conforming, insertted, authoratative, parsible, time
zone -> time zone rule, zone_char -> zone-char, Proceedure, preceeded,
proceeded -> preceded, loosly.


* diff listing covering minor points

--- draft-newman-datetime-01.txt	Wed Jan 29 18:58:38 1997
+++ draft-newman-datetime-01-fix.txt	Wed Jan 29 19:01:52 1997
@@ -41,5 +41,5 @@
      problems on the Internet.  This document will address many of the
      problems encountered and make recommendations to improve
-     consistancy and interoperability when representing and using date
+     consistency and interoperability when representing and using date
      and time in Internet protocols.
 
@@ -61,5 +61,5 @@
       * include rules for day of month and leap seconds
       * disallow hour of 24
-      * add registry of named timezones and local time format
+      * add registry of named time zones and local time format
       * use . instead of , for fractions of second
       * removed references to AM/PM
@@ -76,5 +76,5 @@
       * See controversial issues above.  More comment is welcome.
       * Are more definitions needed?
-      * A number of the timezones in the initial registry list are
+      * A number of the time zones in the initial registry list are
         duplicates for future times.  I already removed the Indiana county
         ones since they all duplicate Indianapolis for future times.
@@ -88,10 +88,12 @@
 
      UTC         Coordinated Universal Time as maintained by the Bureau
-                 Internaational de l'Heure (International Time Bureau).
+                 International des Poids et Mesures and the International
+                 Earth Rotation Service.
 
      second      A basic unit of measurement of time in the
                  International System of Units.
 
-     minute      A period of time of 60 seconds.
+     minute      A period of time, usually of 60 seconds, but occasionally of
+                 59 or 61 seconds when a leap second is subtracted or added.
 
      hour        A period of time of 60 minutes.
@@ -142,7 +144,7 @@
 
      o  If a two digit year is received, the values 00-49 MUST be
-        interpreted as referring to the 21st century (add 2000) and the
-        values 50-99 MUST be interpreted as referring to the 20th
-        century (add 1900).  While different interpretations may result
+        interpreted as referring to the years 2000-2049 (add 2000) and the
+        values 50-99 MUST be interpreted as referring to the years
+        1950-1999 (add 1900).  While different interpretations may result
         in a few more years of 2-digit usability for some applications,
         it is believed that a single interpretation for two digit years
@@ -170,7 +172,8 @@
 
 
-        and adds the decade to the US-ASCII character zero. Programs
+        then divides by ten (discarding any remainder) and adds the result
+        to the US-ASCII character zero. Programs
         wishing to robustly deal with dates generated by such broken
-        software should detect non-numeric decades and interpret
+        software should detect non-numeric tens digits and interpret
         appropriately.
 
@@ -183,5 +186,5 @@
 4.1. Coordinated Universal Time (UTC)
 
-     Because the daylight rules for local timezones are so convoluted
+     Because the daylight-saving rules for local time zones are so convoluted
      and can change based on local law at unpredictable times, true
      interoperability is best achieved by using Coordinated Universal
@@ -202,5 +205,5 @@
      equivalent time in UTC can be determined by subtracting the offset
      from the local time.  For example, 18:50:00-04:00 is the same time
-     as 22:58:00Z.
+     as 22:50:00Z.
 
 
@@ -209,5 +212,5 @@
      If the time in UTC is known, but the offset to local time is
      unknown, this can be represented with an offset of "-00:00".  This
-     differs semanticly from an offset of "Z" which implies that UTC is
+     differs semantically from an offset of "Z" which implies that UTC is
      the preferred reference point for the specified time.  This
      convention MAY also be used in the Email Date/Time Format.
@@ -229,5 +232,5 @@
      specifications, this should not be done at the expense of
      interoperability.  Since interpretation of an unqualified local
-     timezone will fail in approximately 23/24 of the globe, the
+     time zone will fail in approximately 23/24 of the globe, the
      interoperability problems of unqualified local time are deemed
      unacceptable for the Internet.  Devices which are unaware of the
@@ -237,9 +240,9 @@
      o  Use Network Time Protocol [NTP] to obtain the time in UTC.
 
-     o  Use another host in the same local timezone as a gateway to the
+     o  Use another host in the same local time zone as a gateway to the
         Internet.  This host MUST correct unqualified local times before
         they are transmitted to other hosts.
 
-     o  Prompt the user for the local timezone and daylight savings
+     o  Prompt the user for the local time zone and daylight-saving
         settings.
 
@@ -256,5 +259,5 @@
      If date and time components are ordered from least precise to most
      precise, then a useful property is achieved.  Assuming that the
-     timezones of the dates and times are the same (e.g. all in UTC),
+     time zones of the dates and times are the same (e.g. all in UTC),
      then the date and time strings may be sorted as strings (e.g. using
      the strcmp() function in C) and a time-ordered sequence will
@@ -313,5 +316,5 @@
 
      If a date/time format includes redundant information, that
-     introduces the possibility that the redunant information will not
+     introduces the possibility that the redundant information will not
      correlate.  For example, including the day of the week in a
      date/time format introduces the possibility that the day of week is
@@ -343,5 +346,5 @@
 
      The following section defines a profile of ISO 8601 for use on the
-     Internet.  It is a conformant subset of the ISO 8601 extended
+     Internet.  It is a conforming subset of the ISO 8601 extended
      format.  Simplicity is achieved by making most fields and
      punctuation mandatory.
@@ -426,7 +429,7 @@
      Here are three examples of Internet date/time format.
 
-     1985-04-12T23:20:50.52Z
+     1985-04-12T23:20:50.92Z
 
-     This represents 20 minutes and 50.52 seconds after the 23rd hour of
+     This represents 20 minutes and 50.92 seconds after the 23rd hour of
      April 12th, 1985 in UTC.
 
@@ -435,10 +438,10 @@
      This represents 39 minutes and 57 seconds after the 16th hour of
      December 19th, 1996 with an offset of -08:00 from UTC (Pacific
-     Standard Time).  Note that this is equivalent to 1996-12-
-     20T00:39:57Z in UTC.
+     Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+     in UTC.
 
      1990-12-31T23:59:60Z
 
-     This represents the leap second insertted at the end of 1990.
+     This represents the leap second inserted at the end of 1990.
 
 
@@ -455,8 +458,8 @@
      repeating or future dates in local time.  Because the conversion
      rules between UTC and local time may change by season and political
-     whim, it is necessary to label the local time zone with a standard
+     whim, it is necessary to label the local time zone rules with a standard
      label so that if new conversion rules are issued the interpretation
      of the time relative to UTC can be corrected.  For this reason, an
-     IANA registry of timezone names which may be used to represent
+     IANA registry of time zone rule names which may be used to represent
      future dates is necessary.
 
@@ -464,36 +467,36 @@
 6.1. Problems Too Hard to Solve
 
-     Since local timezone rules are set by local governments, the only
-     authoratative reference for such rules is those governments, most
+     Since local time zone rules are set by local governments, the only
+     authoritative reference for such rules is those governments, most
      of which do not currently provide their rules on line in a computer
-     parsible format.  In addition, local timezones were historically
+     parseable format.  In addition, local time zone rules were historically
      set by cities and towns, so attempting to exhaustively enumerate
-     all historical timezones for use in representing past dates is not
-     practical.  Attempting to predict where new timezones will be
-     created as a subset of the area covered by an old timezone is also
+     all historical time zone rules for use in representing past dates is not
+     practical.  Attempting to predict where new time zone rules will be
+     created as a subset of the area covered by an old time zone rule is also
      a hopeless prospect.
 
      Therefore the only formal part of the registry will be names for a
-     minimal set of modern timezones.  As a convenience, the registry
-     will also include the base UTC offset and daylight savings rules
+     minimal set of modern time zone rules.  As a convenience, the registry
+     will also include the base UTC offset and daylight-saving rules
      (if determinable) at the time of registration.  Because the UTC
-     offset and rules may changed by other bodies, they will not be
-     considered an authoratative part of the registry.
+     offset and rules may be changed by other bodies, they will not be
+     considered an authoritative part of the registry.
 
 
 6.2. Prior Art
 
-     An informal collection of timezone information is currently being
+     An informal collection of time zone rule information is currently being
      maintained by volunteer Internet participants.  The current
      location of this information is:
 
-          <ftp://elsie.nci.nih.gov/pub/>
+          <URL:ftp://elsie.nci.nih.gov/pub/>
 
      This is valuable work, and is used in some operating systems.  The
-     initial set of timezone names for the IANA registry is a subset of
+     initial set of time zone rule names for the IANA registry is a subset of
      the names collected by this effort.
 
 
-6.3. Legal Characters in Timezone Names
+6.3. Legal Characters in Time Zone Rule Names
 
      Only the US-ASCII characters A-Z, a-z, 0-9, "-", "_" and "/" are
@@ -506,19 +509,19 @@
 
 
-     legal in timezone names.  The basic format is the name of a
+     legal in time zone rule names.  The basic format is the name of a
      continent or ocean followed by a "/" followed by the name of a city
      or political entity.  A political entity may be followed by a "/"
-     and a subentity if necessary.  Timezone names SHOULD use the
+     and a subentity if necessary.  Time zone rule names SHOULD use the
      standard case in the registry, but MUST be interpreted in a case
-     insensitive manner.   New timezone names SHOULD use "-" rather than
+     insensitive manner.   New time zone rule names SHOULD use "-" rather than
      "_", as the latter is difficult to see in some output contexts.
 
 
-6.4. Template for IANA Registration of Timezone Names
+6.4. Template for IANA Registration of Time Zone Rule Names
 
      To: timezone at XXX
-     Subject: Timezone Name Registration
+     Subject: Time Zone Rule Name Registration
 
-     Timezone Name:
+     Time Zone Rule Name:
 
      ISO 3166 2-character country code:
@@ -527,8 +530,8 @@
 
 
-6.5. Proceedure for IANA Registration of Timezone Names
+6.5. Procedure for IANA Registration of Time Zone Rule Names
 
-     The IESG is responsible for appointing a reviewer of Timezone
-     Names.  The job of this reviewer is to verify that the new timezone
+     The IESG is responsible for appointing a reviewer of Time Zone Rule
+     Names.  The job of this reviewer is to verify that the new time zone rule
      name has unique UTC rules, is likely to be used, fits the rules in
      section 6.3 and does not conflict unnecessarily with prior art
@@ -545,13 +548,13 @@
      In order to assist the reviewer, the address timezone at XXX will be a
      public mailing list where registration proposals may be discussed.
-     Subscription and unsubscription requests may be sent to timezone-
-     request at XXX.
+     Subscription and unsubscription requests may be sent to
+     timezone-request at XXX.
 
 
-6.6. Initial List of IANA Timezone Names
+6.6. Initial List of IANA Time Zone Rule Names
 
-     The following list will serve as the initial list of IANA Timezone
+     The following list will serve as the initial list of IANA Time Zone Rule
      Names.  This list was generated from the archive mentioned in
-     section 6.2.  Some of these timezone names (especially within the
+     section 6.2.  Some of these time zone rule names (especially within the
 
 
@@ -563,9 +566,9 @@
 
      same country) are redundant for future dates, but compatibility
-     with the timezone names in the databases discussed section 6.2. is
+     with the time zone rule names in the databases discussed section 6.2 is
      useful.
 
-     Timezone Name                    Country
-     -------------                    -------
+     Time Zone Rule Name              Country
+     -------------------              -------
      Europe/Andorra                     AD
      Asia/Dubai                         AE
@@ -975,22 +978,22 @@
 
      The following format MAY be used to refer to future dates in a
-     local timezone.  This is defined based on the format in section
+     local time zone.  This is defined based on the format in section
      5.6.
 
-     zone-char = ALPHA / DIGIT / "-" / "_" / "/"
-     zone-name = 1*zone_char
+     zone-rule-char = ALPHA / DIGIT / "-" / "_" / "/"
+     zone-rule-name = 1*zone-rule-char
                     ; case insensitive interpretation
      offset-hint = time-numoffset
 
-     local-datetime = full-date "T" partial-time " " zone-name
+     local-datetime = full-date "T" partial-time " " zone-rule-name
                       [" " offset-hint]
 
      A local-datetime represents an event relative to a specific local
-     timezone.  The offset-hint represents the generator's prediction of
+     time zone rule.  The offset-hint represents the generator's prediction of
      what the UTC offset will be at that local time, and may become
-     incorrect if the rules for the specified zone are changed.  The
+     incorrect if the specified zone rules are changed.  The
      offset-hint MAY be omitted if the generating program only knows
-     local time, but the zone-name is REQUIRED.  This format SHOULD NOT
-     be used for timestamps or past events.
+     local time, but the zone-rule-name is REQUIRED.  This format SHOULD NOT
+     be used for time stamps or past events.
 
 
@@ -1001,5 +1004,5 @@
      1999-12-31T23:59:59 America/New_York -05:00
 
-     This represents a time one (or two if there's a leap second) second
+     This represents a time one second
 
 
@@ -1010,23 +1013,24 @@
 
 
-     before the year 2000 in the timezone used in New York City in North
+     before the year 2000 in the time zone rule used in New York City in North
      America (currently U.S. Eastern Time).  The offset-hint is the
      number to add to the local time to get an estimate UTC for that
      date, so this will probably be equivalent to 2000-01-01T04:59:59Z.
 
-     2000-12-31T23:59:59 Australia/Adelaide +09:30
+     2000-12-31T23:59:59 Australia/Adelaide +10:30
 
-     This represents a time one (or two if there's a leap second) second
-     before the 21st century in Adelaide, Australia.  The hint suggests
-     that this will be equivalent to 2000-12-31T14:29:59Z.
+     This represents a time one second before the year 2001 in
+     Adelaide, Australia.  The hint suggests that this will be
+     equivalent to 2000-12-31T13:29:59Z.
 
      2000-03-31T02:00:00 America/Los_Angeles -08:00
 
      The represents a time of the 2nd hour on the 31st of March in Los
-     Angeles, USA.  The hint suggests that would be equivalent to 2000-
-     03-31T10:00:00Z.  However, if the U.S. government were to adopt the
-     daylight savings rules currently used by the European Union, which
-     change daylight savings on the last Sunday of March, then the time
-     would be equivalent to 2000-03-31T09:00:00Z.
+     Angeles, USA.  The hint suggests that this will be equivalent to
+     2000-03-31T10:00:00Z.  However, if the U.S. government were to adopt the
+     daylight-saving rules currently used by the European Union, which
+     changes to daylight-saving time at 01:00 Coordinated Universal Time
+     on the last Sunday of March, then the time would be equivalent to
+     2000-03-31T09:00:00Z.
 
 
@@ -1037,5 +1041,5 @@
      Kuhn, Paul Eggert and Robert Elz.  Thanks are also due to
      participants of the IETF Calendaring/Scheduling working group
-     mailing list, and participants of the timezone mailing list.
+     mailing list, and participants of the time zone mailing list.
 
 
@@ -1048,5 +1052,5 @@
  Messages", RFC 822, University of Delaware, August 1982.
 
-    <ftp://ds.internic.net/rfc/rfc822.txt>
+    <URL:ftp://ds.internic.net/rfc/rfc822.txt>
 
 [ISO8601] "Data elements and interchange formats -- Information
@@ -1057,5 +1061,5 @@
  and Support", RFC 1123, Internet Engineering Task Force, October 1989.
 
-    <ftp://ds.internic.net/rfc/rfc1123.txt>
+    <URL:ftp://ds.internic.net/rfc/rfc1123.txt>
 
 
@@ -1070,16 +1074,16 @@
  1992.
 
-    <ftp://ds.internic.net/rfc/rfc1305.tar.Z>
-    <ftp://ds.internic.net/rfc/rfc1305.txt>
+    <URL:ftp://ds.internic.net/rfc/rfc1305.tar.Z>
+    <URL:ftp://ds.internic.net/rfc/rfc1305.txt>
 
 [ITU-R-TF] International Telecommunication Union Recommendations for
  Time Signals and Frequency Standards Emissions.
 
-    <http://www.itu.ch/publications/itu-r/iturtf.htm>
+    <URL:http://www.itu.ch/publications/itu-r/iturtf.htm>
 
 
 9. Security Considerations
 
-     Since the local time zone of a site may be useful for determining a
+     Since the local time of a site may be useful for determining a
      time when systems are less likely to be monitored and might be more
      susceptible to a security probe, some sites may wish to emit times
@@ -1104,5 +1108,5 @@
      formats it defines.  The following is an attempt to create a formal
      grammar from ISO 8601.  This is informational only and may contain
-     errors.  ISO 8601 remains the authoratative reference.
+     errors.  ISO 8601 remains the authoritative reference.
 
      Note that due to ambiguities in ISO 8601, some interpretations had
@@ -1123,14 +1127,14 @@
 
      ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
-     be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
-     gives examples where the decimal fractions are not preceeded by a
+     be preceded by a "0" if less than unity.  Annex B.2 of ISO 8601
+     gives examples where the decimal fractions are not preceded by a
      "0".  This grammar assumes section 5.3.1.3 is correct and that
      Annex B.2 is in error.
 
-     date-century    = 2DIGIT  ; 00-99
-     date-decade     =  DIGIT  ; 0-9
-     date-subdecade  =  DIGIT  ; 0-9
-     date-year       = date-decade date-subdecade
-     date-fullyear   = date-century date-year
+     date-hundreds   = 2DIGIT  ; 00-99
+     date-tens-digit =  DIGIT  ; 0-9
+     date-units-digit=  DIGIT  ; 0-9
+     date-year       = date-tens-digit date-units-digit
+     date-fullyear   = date-hundreds date-year
      date-month      = 2DIGIT  ; 01-12
      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
@@ -1139,9 +1143,9 @@
      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
 
-     datepart-fullyear = [date-century] date-year ["-"]
-     datepart-ptyear   = "-" [date-subdecade ["-"]]
+     datepart-fullyear = [date-hundreds] date-year ["-"]
+     datepart-ptyear   = "-" [date-units-digit ["-"]]
      datepart-wkyear   = datepart-ptyear / datepart-fullyear
 
-     dateopt-century   = "-" / date-century
+     dateopt-hundreds  = "-" / date-hundreds
      dateopt-fullyear  = "-" / datepart-fullyear
      dateopt-year      = "-" / (date-year ["-"])
@@ -1150,5 +1154,5 @@
 
      datespec-full     = datepart-fullyear date-month ["-"] date-mday
-     datespec-year     = date-century / dateopt-century date-year
+     datespec-year     = date-hundreds / dateopt-hundreds date-year
      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
      datespec-mday     = "--" dateopt-month date-mday
@@ -1215,5 +1219,5 @@
 B. Day of the Week
 
-     The following is a sample C subroutine loosly based on Zeller's
+     The following is a sample C subroutine loosely based on Zeller's
      Congruence [Zeller] which may be used to obtain the day of the
      week:
@@ -1236,4 +1240,6 @@
      char *day_of_week(int day, int month, int year)
      {
+         int c;
+
          char *dayofweek[] = {
              "Sunday", "Monday", "Tuesday", "Wednesday",
@@ -1247,9 +1253,8 @@
              --year;
          }
-         /* split by century */
-         cent = year / 100;
+         c = year / 100;
          year %= 100;
          return (dayofweek[((26 * month - 2) / 10 + day + year
-                           + year / 4 + cent / 4 - 2 * cent) % 7]);
+                           + year / 4 + c / 4 - 2 * c) % 7]);
      }
 



More information about the tz mailing list