idnits 2.17.1 draft-newman-datetime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '...ternet Protocols MUST generate four di...' RFC 2119 keyword, line 69: '...s received, the values 00-49 SHOULD be...' RFC 2119 keyword, line 71: '... values 50-99 SHOULD be interpreted...' RFC 2119 keyword, line 74: '...hree digit years MUST be interpreted b...' RFC 2119 keyword, line 92: '... offsets are now REQUIRED. When the l...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1996) is 9993 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XXX-ref' is mentioned on line 338, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1119 (ref. 'NTP') (Obsoleted by RFC 1305) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Date and Time on the Internet Innosoft 4 Document: draft-newman-datetime-00.txt December 1996 6 Date and Time on the Internet 8 Status of this memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 IESG as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire six months after publication. Distribution of this draft is 30 unlimited. 32 1. Introduction 34 Date and time formats cause a lot of confusion and interoperability 35 problems on the Internet. This document will address many of the 36 problems encountered and make recommendations to improve 37 consistancy and interoperability when representing and using date 38 and time in Internet protocols. 40 This document includes an Internet profile of the ISO 8601 41 [ISO8601] standard for representation of dates and times. 43 [More detail work is needed, but I wanted to get this out before I 44 go on vacation to see if it meets the basic requirements coming 45 from the ASID and CALSCH working groups. Places needing work are 46 marked with XXX] 48 2. Definitions 50 UTC Coordinated Universal Time as maintained by the Bureau 51 Internaational de l'Heure (International Time Bureau). 53 [XXX definitely need more definitions here. It would be nice to 54 reference a good time standard to define seconds, leap years, etc.] 56 3. Two or Three Digit Years 58 Two digit years are expected to cause great expense to many as the 59 year 2000 approaches. Many existing computer programs simply add 60 or subtract 1900 from a two digit year. Such programs will clearly 61 stop functioning on the year 2000 and will have to be upgraded, 62 possibly at great expense [XXX - ref to Wall Street Journal article 63 on IRS year 2000 problems would be cool]. The following 64 requirements are made of Internet protocols to address this 65 problem: 67 o Internet Protocols MUST generate four digit years in dates. 69 o If a two digit year is received, the values 00-49 SHOULD be 70 interpreted as referring to the 21st century (add 2000) and the 71 values 50-99 SHOULD be interpreted as referring to the 20th century 72 (add 1900). 74 o Three digit years MUST be interpreted by adding 1900. 76 4. Local Time 78 4.1. Coordinated Universal Time (UTC) 80 Because the daylight rules for local timezones are so convoluted 81 [XXX-ref], true interoperability is best achieved by using 82 Coordinated Universal Time (UTC) [XXX-ref]. 84 4.2. Local Offsets 86 The offset between local time and UTC is often useful information. 87 For example, in electronic mail [IMAIL] the local offset provides a 88 useful heuristic to determine the probability of a prompt response. 89 Attempts to label local offsets with alphabetic strings have met 90 with poor interoperability results in the past [IMAIL], [HOST-REQ]. 92 Therefore numeric offsets are now REQUIRED. When the local offset 93 is unknown, the offset "-00:00" MAY be used to indicate that the 94 time is in UTC and the local offset is unknown. 96 4.3. Unqualified Local Time 98 A number of devices currently connected to the Internet run their 99 internal clocks in local time and are unaware of UTC. While the 100 Internet does have a tradition of accepting reality when creating 101 specifications, this should not be done at the expense of 102 interoperability. Since interpretation of an unqualified local 103 timezone will fail in approximately 23/24 of the globe, the 104 interoperability problems of unqualified local time are deemed 105 unacceptable for the Internet. Devices which are unaware of the 106 time in UTC MUST use one of the following techniques when 107 communicating on the Internet: 109 o Use Network Time Protocol [NTP] to obtain the time in UTC. 111 o Use another host in the same local timezone as a gateway to the 112 Internet. This host MUST correct unqualified local times before 113 they are transmitted to other hosts. 115 o Prompt the user for the local timezone if it is aware of the 116 daylight rules. One technique to do this is by having the user 117 select a major city in their timezone. An alternative would be to 118 show a list of the timezone labels defined in [section XXX]. 120 5. Date and Time formats 122 The date and time format defined in [IMAIL] and as amended by 123 [HOST-REQ] may be referred to as "the Internet Mail Date/Time 124 Format". The profile of ISO 8601 defined in this section may be 125 referred to as "the Internet Date/Time Format". The following 126 sections describe useful properties of a date and time format for 127 interchange on the Internet. 129 5.1. Ordering 131 If date and time components are ordered from least precise to most 132 precise, then a useful property is achieved. Assuming that the 133 timezones of the dates and times are the same (e.g. all in UTC), 134 then the date and time strings may be sorted as strings (e.g. using 135 the strcmp() function in C) and a time-ordered sequence will 136 result. The presence of optional punctuation would violate this 137 characteristic. 139 5.2. Human Readability 141 Human readability has proved to be a valuable feature of Internet 142 protocols. Human readable protocols greatly reduce the costs of 143 debugging since telnet often suffices as a test client and network 144 analysers need not be modified with knowledge of the protocol. On 145 the other hand, human readability sometimes results in 146 interoperability problems. For example, the date format 147 "10/11/1996" is completely unsuitable for global interchange 148 because it is interpreted differently in different countries. In 149 addition, the date format in [IMAIL] has resulted in 150 interoperability problems when people assumed it was simply a text 151 string and translated the three letter abbreviations to other 152 languages or substituted date formats which were easier to generate 153 (e.g. the format used by the C function ctime). For this reason, a 154 balance must be struck between human readability and 155 interoperability. 157 Because no date and time format is readable according to the 158 conventions of all countries, Internet clients SHOULD be prepared 159 to transform dates into a display format suitable for the locality. 160 This includes translating UTC to local time. 162 5.3. Simplicity 164 The complete set of date and time formats specified in ISO 8601 165 [ISO8601] is quite complex in an attempt to provide multiple 166 representations and partial representations. Appendix A contains 167 an attempt to translate the complete syntax of ISO 8601 into ABNF 168 as defined in [IMAIL]. Internet protocols have somewhat different 169 requirements and simplicity has proved to be an important 170 characteristic. In addition, Internet protocols usually need 171 complete specification of data in order to achieve true 172 interoperability. Therefore, the complete grammar for ISO 8601 is 173 deemed too complex for most Internet protocols. 175 The following section defines an profile of ISO 8601 for use on the 176 Internet. It is a conformant subset of the ISO 8601 extended 177 format. Simplicity is achieved by making most fields and 178 punctuation mandatory. 180 5.4. Internet Date/Time Format 181 The following profile of ISO 8601 [ISO8601] dates SHOULD be used in 182 new protocols on the Internet. This is specified using ABNF as 183 defined in [IMAIL]. 185 date-fullyear = 4DIGIT 186 date-month = 2DIGIT ; 01-12 187 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 188 time-hour = 2DIGIT ; 00-24 189 time-minute = 2DIGIT ; 00-59 190 time-second = 2DIGIT ; 00-60 191 time-secfrac = "," 1*DIGIT 192 time-numzone = ("+" / "-") time-hour ":" time-minute 193 time-zone = "Z" / time-numzone 195 full-date = date-fullyear "-" date-month "-" date-mday 196 full-time = time-hour ":" time-minute ":" time-second 197 [time-secfrac] time-zone 199 date-time = full-date "T" full-time 201 5.5 Examples 203 Here are two examples of this date and time format. 205 1985-04-12T23:20:50,5Z 207 This represents 20 minutes and 50.5 seconds after 11 PM on April 208 12th, 1985 in UTC. 210 1996-12-19T16:39:57-08:00 212 This represents 39 minutes and 57 seconds after 4 PM on December 213 19th, 1996 with an offset of -08:00 from UTC (Pacific Standard 214 Time). 216 6. IANA Registry of Timezone Names 218 [XXX - put good stuff here] 220 7. References 222 [ISO8601] "Data elements and interchange formats -- Information 223 interchange -- Representation of dates and times", ISO 8601:1988(E), 224 International Organization for Standardization, June, 1988. 226 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 227 Messages", RFC 822, University of Delaware, August 1982. 229 231 [HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application 232 and Support", RFC 1123, Internet Engineering Task Force, October 1989. 234 236 [NTP] Mills, D., "Network Time Protocol version 2 specification and 237 implementation", RFC 1119, September 1989. 239 241 8. Security Considerations 243 Since the local time zone of a site may be useful for determining a 244 time when systems are less likely to be monitored and might be more 245 susceptible to a security probe, some sites may wish to emit times 246 in UTC only. Others might consider this to be loss of useful 247 functionality at the hands of paranoia. 249 9. Author's Address 251 Chris Newman 252 Innosoft International, Inc. 253 1050 East Garvey Ave. South 254 West Covina, CA 91790 USA 256 Email: chris.newman@innosoft.com 258 APPENDIX 260 A. ISO 8601 Collected ABNF 262 ISO 8601 does not specify a formal grammar for the date and time 263 formats it defines. The following is an attempt to create a formal 264 grammar from ISO 8601. This is informational only and may contain 265 errors. ISO 8601 remains the authoratative reference for the 266 complete syntax. 268 date-century = 2DIGIT ; 00-99 269 date-decade = DIGIT ; 0-9 270 date-subdecade = DIGIT ; 0-9 271 date-year = date-decade date-subdecade 272 date-fullyear = date-century date-year 273 date-month = 2DIGIT ; 01-12 274 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday 275 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 276 date-yday = 3DIGIT ; 001-365, 001-366 based on year 277 date-week = 2DIGIT ; 01-52, 01-53 based on year 279 datepart-fullyear = [date-century] date-year ["-"] 280 datepart-ptyear = "-" [date-subdecade ["-"]] 281 datepart-wkyear = datepart-ptyear / datepart-fullyear 283 dateopt-century = "-" / date-century 284 dateopt-fullyear = "-" / datepart-fullyear 285 dateopt-year = "-" / (date-year ["-"]) 286 dateopt-month = "-" / (date-month ["-"]) 287 dateopt-week = "-" / (date-week ["-"]) 289 datespec-full = datepart-fullyear date-month ["-"] date-mday 290 datespec-year = date-century / dateopt-century date-year 291 datespec-month = "-" dateopt-year date-month [["-"] date-mday] 292 datespec-mday = "--" dateopt-month date-mday 293 datespec-week = datepart-wkyear "W" (date-week / dateopt-week date-wday) 294 datespec-wday = "---" date-wday 295 datespec-yday = dateopt-fullyear date-yday 297 date = datespec-full / datespec-year / datespec-month / 298 datespec-mday / datespec-week / datespec-wday / datespec-yday 300 Time: 302 time-hour = 2DIGIT ; 00-24 303 time-minute = 2DIGIT ; 00-59 304 time-second = 2DIGIT ; 00-60 305 time-fraction = ("," / ".") 1*DIGIT 306 time-numzone = ("+" / "-") time-hour [[":"] time-minute] 307 time-zone = "Z" / time-numzone 309 timeopt-hour = "-" / (time-hour [":"]) 310 timeopt-minute = "-" / (time-minute [":"]) 312 timespec-hour = time-hour [[":"] time-minute [[":"] time-second]] 313 timespec-minute = timeopt-hour time-minute [[":"] time-second] 314 timespec-second = "-" timeopt-minute time-second 315 timespec-base = timespec-hour / timespec-minute / timespec-second 317 time = timespec-base [time-fraction] [time-zone] 319 iso-date-time = date "T" time 320 Durations (periods): 322 dur-second = 1*DIGIT "S" dur-minute = 1*DIGIT "M" 323 [dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time 324 = "T" (dur-hour / dur-minute / dur-second) dur-day = 325 1*DIGIT "D" dur-week = 1*DIGIT "W" dur-month = 326 1*DIGIT "M" [dur-day] dur-year = 1*DIGIT "Y" [dur-month] 327 dur-date = (dur-day / dur-month / dur-year) [dur-time] 329 duration = "P" (dur-date / dur-time / dur-week) 331 Periods: 333 period-explicit = date-time "/" date-time period-start = 334 date-time "/" duration period-end = duration "/" date-time 336 period = period-explicit / period-start / period-end 338 B. Zeller's Congruence [XXX-ref] 340 The following is sample C code which may be used to obtain the day 341 of the week: 343 char *dayofweek[] = { 344 "Sunday", "Monday", "Tuesday", "Wednesday", 345 "Thursday", "Friday", "Saturday" 346 }; 348 void main() 349 { 350 int cent, year, day, month; 352 printf("Enter the year (4 digits): "); 353 scanf("%d", &year); 354 printf("\nEnter the month (1-12): "); 355 scanf("%d", &month); 356 printf("\nEnter the day of the month (1-31): "); 357 scanf("%d", &day); 358 month -= 2; 359 if (month < 1) { 360 month += 12; 361 year--; 362 } 363 cent = year / 100; 364 year %= 100; 365 printf("The day of the week is: %s\n", 366 dayofweek[((26 * month - 2) / 10 + day + year 367 + year / 4 + cent / 4 - 2 * cent) % 7]); 368 }