I-D ACTION:draft-newman-datetime-01.txt (fwd)
Here's a new version of the time format document. The major change is adding a new format to represent future dates by specifying timezone name. Something like this seems to be needed by the IETF calendaring/scheduling working group to deal with future events and recurring events scheduled in local timezones. ---------- Forwarded message ---------- Date: Tue, 28 Jan 1997 09:40:43 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-newman-datetime-01.txt A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Date and Time on the Internet Author(s) : C. Newman Filename : draft-newman-datetime-01.txt Pages : 23 Date : 01/27/1997 Date and time formats cause a lot of confusion and interoperability 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 and time in Internet protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-newman-datetime-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-datetime-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-datetime-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
In message <Pine.SOL.3.95.970128101451.29431P-120000@eleanor.innosoft.com>, Chris Newman wrote:
ftp://ds.internic.net/internet-drafts/draft-newman-datetime-01.txt
6.8. Examples Here are some examples of Local Date/Time Format: 1999-12-31T23:59:59 America/New_York -05:00 This represents a time one (or two if there's a leap second) second before the year 2000 in the timezone 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. Thanks for the new draft. Here are again some comments on it from me: 1) Format If it is really necessary to include a registered time zone algorithm identifier, then I would prefer to see it appended to the ISO 8601 string as in 1999-12-31T23:59:59-05:00/America/New_York If you allow to insert a fields between the time and offset (which is not supported by ISO 8601) and insert spaces into the format, then this is a serious deviation from ISO 8601 and you could also allow the replacement of the "T" by a space as well ... 2) Logic errors in above example Leap seconds are always inserted before midnight UTC, so 23:59:59 is exactly one second before the start of the year 2000 in New York, and not possibly two seconds (the potential leap second on this day in New York would be 1999-12-31 18:59:60-05). "The offset hint is the number to SUBTRACT FROM the local time to get ..." not "add to". There are still lots of typos that require very careful proofreading. 3) Rounding of timestamps: I have one additional suggestion: The spec should mention that if time is known to the system with a higher precision than displayed, then the displayed time should be truncated and NOT rounded. I know software that displays minute precision (e.g. PGP) and adds 30 s before tuncating in order to round to the nearest full minute. I consider this time rounding to be highly counter-intuitive, as users of digital watches expect the display to flip over at the start of the minute or second, and not half a minute or second earlier due to rounding. In order words, the time 23:59:59 should be displayed during any point t in time with 23:59:59.000 <= t < 24:00:00.000, in order to ensure consistency with the common digital clock semantics (ISO 8601 is unfortunately silent about this). 4) Time zone registry The suggested template for a time zone registration request should contain a formal notation for the time zone algorithm. Candidates are the zic and the POSIX TZ formats, with the former one being much more flexible. So far, on the tz list, suggested changes have been communicated for review in the form of diff patches to the tz database zic sources, which eliminates many possible missunderstandings that are very like to occur in a time zone algorithm communicated in English. The nature of the name space (time zone identified by the English name of the largest populated ares in this zone, etc.) should be specified and a rationale should be given for it (see the tz africa file for Paul's background information about the namespace design). The description of the role and purpose of the IANA time zone registry is a little bit unclear. As I understand it, you want to register a list of location descriptors, that can be used to identify the current time zone in effect at any point in time at this location and at locations that share the same time zone algorithm as the identified location. If this is the case, then in addition to the ISO country code, the registry should contain a reference coordinate that identifies the registered location. Such a coordinate file is already part of the tz package (zone.tab). During the switch from summer time back to winter time, usually one hour occurs twice. Your local format (as now the location identifier and not the offset is authoritative) distinguishes not any more uniquely between these two hours. Suggestion: The European laws that define the time zones there define for localtime timestamps that occur twice to append an A after the first occurence and a B after the second occurence. For example: 02:30A Europe/Paris = 00:30 UTC 02:30B Europe/Paris = 01:30 UTC The A/B technique corresponds essentially to the tm_isdst flag used in the C library for distinguishing between ambiguous localtime timestamps during the switch (if there is one). Something like this might be worth being added to the format. (Yes, ISO 8601 does not provide for it, but ISO 8601 also assumes fixes specified UTC offsets and not location identifiers instead.) Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu
Thanks for the helpful comments! On Tue, 28 Jan 1997, Markus G. Kuhn wrote:
1) Format
If it is really necessary to include a registered time zone algorithm identifier, then I would prefer to see it appended to the ISO 8601 string as in
1999-12-31T23:59:59-05:00/America/New_York
If you allow to insert a fields between the time and offset (which is not supported by ISO 8601) and insert spaces into the format, then this is a serious deviation from ISO 8601 and you could also allow the replacement of the "T" by a space as well ...
I do believe we need a new format for future times where the timezone name is authoratative, it could potentially be split into a separate document if that was thought to be helpful. The primary need for this is to specify future and recurring events for the calendaring and scheduling work. The zone offset hint in the local format has very different semantics from the zone offset in ISO 8601, so I felt it was important to use a different syntax for it. The basic idea was to take the ISO 8601 local time format, append the timezone name to fully qualify it, then the optional offset hint. As far as I'm concerned, any reasonable syntax for the stuff after the ISO 8601 local time is fair game.
2) Logic errors in above example
Thanks. I'll fix those in the next draft.
3) Rounding of timestamps:
Good idea. I'll add it in the next draft.
4) Time zone registry
What I wanted to avoid was having the IETF/IANA take over the work currently being done by the timezone mailing list to maintain the timezone archives. What I wanted to do was to give a "standards blessing" to the names used in the timezone archive, without pretending that the IANA (or anyone on the Internet) can keep a set of zone rules which have standards-level authority.
The suggested template for a time zone registration request should contain a formal notation for the time zone algorithm. Candidates are the zic and the POSIX TZ formats, with the former one being much more flexible.
The POSIX format is obviously inadequate. But I really don't want IANA to register the zone rules -- I just want a registry of the zone names. The zone rules can be found two ways: through informal channels on the Internet, or by contacting the appropriate government. Frankly, I think this list is doing a superb job of maintaining zone rule archives and have no interest in competing with it or mucking with the current functional process.
The nature of the name space (time zone identified by the English name of the largest populated ares in this zone, etc.) should be specified and a rationale should be given for it (see the tz africa file for Paul's background information about the namespace design).
Good idea. I didn't notice that before. I will suggest one change to Paul's rules -- namely that "-" be used to represent spaces in future names rather than "_". It turns out that "_" causes problems in a number of contexts (some non-english countries, underlined words, terminal screen with blinking underscore cursor, some printing contexts).
The description of the role and purpose of the IANA time zone registry is a little bit unclear.
Yeah. I'll work on it.
the case, then in addition to the ISO country code, the registry should contain a reference coordinate that identifies the registered location.
That does make sense. Agreed.
During the switch from summer time back to winter time, usually one hour occurs twice. Your local format (as now the location identifier and not the offset is authoritative) distinguishes not any more uniquely between these two hours.
True. Summer time is really a pain. Your suggestion is quite reasonable -- I'll add it to the next draft.
In message <Pine.SOL.3.95.970128144355.29431n-100000@eleanor.innosoft.com>, Chr is Newman wrote:
The nature of the name space (time zone identified by the English name of the largest populated ares in this zone, etc.) should be specified and a rationale should be given for it (see the tz africa file for Paul's background information about the namespace design).
Good idea. I didn't notice that before.
I believe, many first-time readers of the tz package do not find this quite important information, which is very well hidden in the comments of the africa file. I would suggest to remove the namespace design guidelines from the africa file and put them into a separate clearly visible documentation file (README, Theory, Design, etc.) such that first time users who wonder about the concept behind the names can find it more easily.
The description of the role and purpose of the IANA time zone registry is a little bit unclear.
Yeah. I'll work on it.
Ok, with the additional explanations in your reply, many thinks in your draft start to make much more sense to me. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu
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@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@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@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@XXX will be a public mailing list where registration proposals may be discussed. - Subscription and unsubscription requests may be sent to timezone- - request@XXX. + Subscription and unsubscription requests may be sent to + timezone-request@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]); }
The majority of what I didn't comment on, I agree with and will fix. On Wed, 29 Jan 1997, Paul Eggert wrote:
(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.
The problem with making the UTC offset hint mandatory in all cases is that it is quite possible that a computer will know the standard timezone name, but not be able to compute future UTC offsets. Since the time is unambiguous (except during offset shift times), I believe it's reasonable and useful to allow the UTC offset hint to be omitted by such computers. Asia/Tel_Aviv is another case where omitting the UTC offset hint for future dates might be a good idea (especially near the end of March).
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.
I agree with your argument, but I have a lot of expertise in IETF history, and I expect opposition to using "_". For the next draft, I'll try to include a similar explaination and see if I can get away with it in IETF circles.
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.
I'll confirm that: A) ISO 8601 permits "T" to be omitted by mutual agreement. and B) ISO 8601 does not permit " " to be used anywhere in the format. As I posted earlier, I think the right solution is to require the "T" for Internet protocol interoperability, but suggest that subtituting a " " for the "T" is reasonable when displaying to a human.
``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''.
I mention "Email Date/Time Format", which is the format defined by RFC 822 and updated by RFC 1123. Two digit years are legal (but not recommended) in that format. I'll add a clarification that two digit years are not legal in the Internet Date/Time Format.
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.
I'll consider removing it, or restructuring it a bit. I like to warn people of problems they're likely to encounter. I suspect the number of EBCDIC generators remaining on the Internet is not signficiant enough to merit this type of warning.
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".
Email Date/Time format recommends that only numeric zones be used. The "-00:00" idea came from discussions about that format on the DRUMS (Detailed Revision and Update of Messaging Standards) mailing list and the idea was popular. I'll give another try at clarifying the wording.
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).
Case-insensitivity is very popular in the IETF. On the other hand, if the "T" and "Z" are case-sensitive, then the zone rules probably should be as well for consistancy. I'll try changing this.
6.4. I suggest that IANA coordinate with tz@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@elsie.nci.nih.gov to set this up.
That's a good idea. The only concern I have is that since RFC's are permanent publications, it's best to try to find a host name which is expected to be permanently available. Current practice in the IETF is to use "ietf.org" for XXX. I will try to make it clear that best efforts will be made to coordinate the formal name registry with the informal name/rules registry maintained by the tz list.
6.5. I'll volunteer to review time zone rule names, if that helps.
I'd appreciate that.
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.
As I explained to Markus, I think there is an important distinction between a UTC offset (which is authoratative) and an offset hint (which may not be correct). I'm quite reluctant to use the same syntax for both.
Also, why is this format constrained to future dates? Please explain why this constraint is needed.
There isn't any current or proposed Internet Protocol which uses historical dates. A list of all historical time zones is much larger and much more difficult to implement on small devices (like a calendaring PDA). I like to solve the smallest problem that needs to be solved when it simplifies the result. Present and near-past dates can be represented using ISO 8601 unambiguously and it's a far simpler format to process. As far as I'm concerned, a format using time zone rule names is a necessary evil that should be avoided whenever possible.
The document sometimes breaks lines improperly (e.g. `1996-12- 20T00:39:57Z').
Anyone know how to fix this using troff?
6.2 (and other sections). Use <URL:...> syntax as per RFC 1738.
Since the <URL:...> syntax is not common practice, the next revision of the URL specification (currently: <ftp://ds.internic.net/internet-drafts/draft-fielding-url-syntax-03.txt>) no longer recommends this. Personally, I think it's ugly and modern free-text URL recognizers find URLs in unadorned <> just fine.
participants (3)
-
Chris Newman -
kuhn＠cs.purdue.edu -
Paul Eggert