idnits 2.17.1 draft-ietf-impp-datetime-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 9 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([ISO8601]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 158: '...ternet Protocols MUST generate four di...' RFC 2119 keyword, line 179: '...ternet protocols MUST be fully qualifi...' RFC 2119 keyword, line 232: '...ith other Internet systems, MUST use a...' RFC 2119 keyword, line 239: '...rnet. This host MUST correct unqualif...' RFC 2119 keyword, line 279: '...Internet clients SHOULD be prepared to...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (3 July 2001) is 8326 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Zeller' ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL-UPDATE') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' -- Possible downref: Non-RFC (?) normative reference: ref. 'IERS' ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-R-TF' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Klyne, Baltimore Technologies 2 Internet Draft C. Newman, Sun Microsystems 3 3 July 2001 4 Expires: January 2002 6 Date and Time on the Internet: Timestamps 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Copyright Notice 38 Copyright (C) The Internet Society 2001. All Rights Reserved. 40 Abstract 42 This document defines a date and time format for use in Internet 43 protocols that is a profile of the ISO 8601 [ISO8601] standard for 44 representation of dates and times using the Gregorian calendar. 46 Table of Contents 48 1. Introduction 49 2. Definitions 50 3. Two Digit Years 51 4. Local Time 52 4.1. Coordinated Universal Time (UTC) 53 4.2. Local Offsets 54 4.3. Unknown Local Offset Convention 55 4.4. Unqualified Local Time 56 5. Date and Time format 57 5.1. Ordering 58 5.2. Human Readability 59 5.3. Rarely Used Options 60 5.4. Redundant Information 61 5.5. Simplicity 62 5.6. Internet Date/Time Format 63 5.7. Restrictions 64 5.8. Examples 65 6. Acknowledgements 66 7. References 67 8. Security Considerations 68 9. Authors' Addresses 69 Appendix A. ISO 8601 Collected ABNF 70 Appendix B. Day of the Week 71 Appendix C. Leap Years 72 Appendix D. Leap Seconds 73 Appendix E. Amendment history 74 Full copyright statement 76 1. Introduction 78 Date and time formats cause a lot of confusion and interoperability 79 problems on the Internet. This document addresses many of the 80 problems encountered and makes recommendations to improve consistency 81 and interoperability when representing and using date and time in 82 Internet protocols. 84 This document includes an Internet profile of the ISO 8601 [ISO8601] 85 standard for representation of dates and times using the Gregorian 86 calendar. 88 There are many ways in which date and time values might appear in 89 Internet protocols: this document focuses on just one common usage, 90 viz. timestamps for Internet protocol events. This limited 91 consideration has the following consequences: 93 o All dates and times are assumed to be in the "current era", 94 somewhere between 0000AD and 9999AD. 96 o All times expressed have a stated relationship (offset) to 97 Coordinated Universal Time (UTC). (This is distinct from some 98 usage in scheduling applications where a local time and location 99 may be known, but the actual relationship to UTC may be dependent 100 on the unknown or unknowable actions of politicians or 101 administrators. The UTC time corresponding to 17:00 on 23rd March 102 2005 in New York may depend on administrative decisions about 103 daylight savings time. This specification steers well clear of 104 such considerations.) 106 o Timestamps can express times that occurred before the introduction 107 of UTC. Such timestamps are expressed relative to universal time, 108 using the best available practice at the stated time. 110 o Date and time expressions indicate an instant in time. 111 Description of time periods, or intervals, is not covered here. 113 2. Definitions 115 UTC Coordinated Universal Time as maintained by the Bureau 116 International des Poids et Mesures (BIPM). 118 second A basic unit of measurement of time in the International 119 System of Units. It is defined as the duration of 120 9,192,631,770 cycles of microwave light absorbed or 121 emitted by the hyperfine transition of cesium-133 atoms 122 in their ground state undisturbed by external fields. 124 minute A period of time of 60 seconds. However, see also the 125 restrictions in section 5.7 and Appendix D for how leap 126 seconds are denoted within minutes. 128 hour A period of time of 60 minutes. 130 day A period of time of 24 hours. 132 leap year In the Gregorian calendar, a year which has 366 days. A 133 leap year is a year whose number is divisible by four an 134 integral number of times, except that if it is a 135 centennial year (i.e. divisible by one hundred) it shall 136 also be divisible by four hundred an integral number of 137 times. 139 ABNF Augmented Backus-Naur Form, a format used to represent 140 permissible strings in a protocol or language, as defined 141 in [ABNF]. 143 Email Date/Time Format 144 The date/time format used by Internet Mail as defined by 145 RFC 2822 [IMAIL-UPDATE]. 147 Internet Date/Time Format 148 The date format defined in section 5 of this document. 150 For more information about time scales, see Appendix E of [NTP], 151 Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF]. 153 3. Two Digit Years 155 The following requirements are to address the problems of ambiguity 156 of 2-digit years: 158 o Internet Protocols MUST generate four digit years in dates. 160 o The use of 2-digit years is deprecated. If a 2-digit year is 161 received, it should be accepted ONLY if an incorrect 162 interpretation will not cause a protocol or processing failure 163 (e.g. if used only for logging or tracing purposes). 165 o It is possible that a program using two digit years will represent 166 years after 1999 as three digits. This occurs if the program 167 simply subtracts 1900 from the year and doesn't check the number 168 of digits. Programs wishing to robustly deal with dates generated 169 by such broken software may add 1900 to three digit years. 171 o It is possible that a program using two digit years will represent 172 years after 1999 as ":0", ":1", ... ":9", ";0", ... This occurs 173 if the program simply subtracts 1900 from the year and adds the 174 decade to the US-ASCII character zero. Programs wishing to 175 robustly deal with dates generated by such broken software should 176 detect non-numeric decades and interpret appropriately. 178 The problems with two digit years amply demonstrate why all dates 179 and times used in Internet protocols MUST be fully qualified. 181 4. Local Time 183 4.1. Coordinated Universal Time (UTC) 185 Because the daylight saving rules for local time zones are so 186 convoluted and can change based on local law at unpredictable times, 187 true interoperability is best achieved by using Coordinated Universal 188 Time (UTC). This specification does not cater to local time zone 189 rules. 191 4.2. Local Offsets 193 The offset between local time and UTC is often useful information. 194 For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local 195 offset provides a useful heuristic to determine the probability of a 196 prompt response. Attempts to label local offsets with alphabetic 197 strings have resulted in poor interoperability in the past [IMAIL], 198 [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric 199 offsets mandatory. 201 Numeric offsets are calculated as "local time minus UTC". So the 202 equivalent time in UTC can be determined by subtracting the offset 203 from the local time. For example, 18:50:00-04:00 is the same time as 204 22:50:00Z. 206 NOTE: Following ISO 8601, numeric offsets represent only time 207 zones that differ from UTC by an integral number of minutes. 208 However, many historical time zones differ from UTC by a non- 209 integral number of minutes. To represent such historical time 210 stamps exactly, applications must convert them to a representable 211 time zone. 213 4.3. Unknown Local Offset Convention 215 If the time in UTC is known, but the offset to local time is unknown, 216 this can be represented with an offset of "-00:00". This differs 217 semantically from an offset of "Z" or "+00:00", which imply that UTC 218 is the preferred reference point for the specified time. RFC2822 219 [IMAIL-UPDATE] describes a similar convention for email. 221 4.4. Unqualified Local Time 223 A number of devices currently connected to the Internet run their 224 internal clocks in local time and are unaware of UTC. While the 225 Internet does have a tradition of accepting reality when creating 226 specifications, this should not be done at the expense of 227 interoperability. Since interpretation of an unqualified local time 228 zone will fail in approximately 23/24 of the globe, the 229 interoperability problems of unqualified local time are deemed 230 unacceptable for the Internet. Systems that are configured with a 231 local time, are unaware of the corresponding UTC offset, and depend 232 on time synchronization with other Internet systems, MUST use a 233 mechanism that ensures correct synchronization with UTC. Some 234 suitable mechanisms are: 236 o Use Network Time Protocol [NTP] to obtain the time in UTC. 238 o Use another host in the same local time zone as a gateway to the 239 Internet. This host MUST correct unqualified local times they are 240 transmitted to other hosts. 242 o Prompt the user for the local time zone and daylight saving rule 243 settings. 245 5. Date and Time format 247 This section discusses desirable qualities of date and time formats 248 and defines a profile of ISO 8601 for use in Internet protocols. 250 5.1. Ordering 252 If date and time components are ordered from least precise to most 253 precise, then a useful property is achieved. Assuming that the time 254 zones of the dates and times are the same (e.g. all in UTC), 255 expressed using the same string (e.g. all "Z" or all "+00:00"), and 256 all times have the same number of fractional second digits, then the 257 date and time strings may be sorted as strings (e.g. using the 258 strcmp() function in C) and a time-ordered sequence will result. The 259 presence of optional punctuation would violate this characteristic. 261 5.2. Human Readability 263 Human readability has proved to be a valuable feature of Internet 264 protocols. Human readable protocols greatly reduce the costs of 265 debugging since telnet often suffices as a test client and network 266 analyzers need not be modified with knowledge of the protocol. On 267 the other hand, human readability sometimes results in 268 interoperability problems. For example, the date format "10/11/1996" 269 is completely unsuitable for global interchange because it is 270 interpreted differently in different countries. In addition, the 271 date format in [IMAIL] has resulted in interoperability problems when 272 people assumed any text string was permitted and translated the three 273 letter abbreviations to other languages or substituted date formats 274 which were easier to generate (e.g. the format used by the C function 275 ctime). For this reason, a balance must be struck between human 276 readability and interoperability. 278 Because no date and time format is readable according to the 279 conventions of all countries, Internet clients SHOULD be prepared to 280 transform dates into a display format suitable for the locality. 281 This may include translating UTC to local time. 283 5.3. Rarely Used Options 285 A format which includes rarely used options is likely to cause 286 interoperability problems. This is because rarely used options are 287 less likely to be used in alpha or beta testing, so bugs in parsing 288 are less likely to be discovered. Rarely used options should be made 289 mandatory or omitted for the sake of interoperability whenever 290 possible. 292 The format defined below includes only one rarely used option: 293 fractions of a second. It is expected that this will be used only by 294 applications which require strict ordering of date/time stamps or 295 which have an unusual precision requirement. 297 5.4. Redundant Information 299 If a date/time format includes redundant information, that introduces 300 the possibility that the redundant information will not correlate. 301 For example, including the day of the week in a date/time format 302 introduces the possibility that the day of week is incorrect but the 303 date is correct, or vice versa. Since it is not difficult to compute 304 the day of week from a date (see Appendix B), the day of week should 305 not be included in a date/time format. 307 5.5. Simplicity 309 The complete set of date and time formats specified in ISO 8601 310 [ISO8601] is quite complex in an attempt to provide multiple 311 representations and partial representations. Appendix A contains an 312 attempt to translate the complete syntax of ISO 8601 into ABNF. 313 Internet protocols have somewhat different requirements and 314 simplicity has proved to be an important characteristic. In 315 addition, Internet protocols usually need complete specification of 316 data in order to achieve true interoperability. Therefore, the 317 complete grammar for ISO 8601 is deemed too complex for most Internet 318 protocols. 320 The following section defines a profile of ISO 8601 for use on the 321 Internet. It is a conformant subset of the ISO 8601 extended format. 322 Simplicity is achieved by making most fields and punctuation 323 mandatory. 325 5.6. Internet Date/Time Format 327 The following profile of ISO 8601 [ISO8601] dates SHOULD be used in 328 new protocols on the Internet. This is specified using the syntax 329 description notation defined in [ABNF]. 331 date-fullyear = 4DIGIT 332 date-month = 2DIGIT ; 01-12 333 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 334 time-hour = 2DIGIT ; 00-23 335 time-minute = 2DIGIT ; 00-59 336 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules 337 time-secfrac = "." 1*DIGIT 338 time-numoffset = ("+" / "-") time-hour ":" time-minute 339 time-offset = "Z" / time-numoffset 341 partial-time = time-hour ":" time-minute ":" time-second 342 [time-secfrac] 343 full-date = date-fullyear "-" date-month "-" date-mday 344 full-time = partial-time time-offset 346 date-time = full-date "T" full-time 348 NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in 349 this syntax may alternatively be lower case "t" or "z" 350 respectively. 352 NOTE: ISO 8601 defines date and time separated by "T". 353 Applications using this syntax may choose, for the sake of 354 readability, to specify a full-date and full-time separated by 355 (say) a space character. 357 5.7. Restrictions 359 The grammar element date-mday represents the day number within the 360 current month. The maximum value varies based on the month and year 361 as follows: 363 Month Number Month/Year Maximum value of date-mday 364 ------------ ---------- -------------------------- 365 01 January 31 366 02 February, normal 28 367 02 February, leap year 29 368 03 March 31 369 04 April 30 370 05 May 31 371 06 June 30 372 07 July 31 373 08 August 31 374 09 September 30 375 10 October 31 376 11 November 30 377 12 December 31 379 Appendix C contains sample C code to determine if a year is a leap 380 year. 382 The grammar element time-second may have the value "60" at the end of 383 months in which a leap second occurs -- to date: June 384 (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see 385 Appendix D for a table of leap seconds. It is also possible for a 386 leap second to be subtracted, at which times the maximum value of 387 time-second is "58". At all other times the maximum value of 388 time-second is "59". Further, in time zones other than "Z", the leap 389 second point is shifted by the zone offset (so it happens at the same 390 instant around the globe). 392 Leap seconds cannot be predicted far into the future. The 393 International Earth Rotation Service publishes bulletins [IERS] that 394 announce leap seconds with a few weeks' warning. Applications should 395 not generate timestamps involving inserted leap seconds until after 396 the leap seconds are announced. 398 Although ISO 8601 permits the hour to be "24", this profile of ISO 399 8601 only allows values between "00" and "23" for the hour in order 400 to reduce confusion. 402 5.8. Examples 404 Here are some examples of Internet date/time format. 406 1985-04-12T23:20:50.52Z 408 This represents 20 minutes and 50.52 seconds after the 23rd hour of 409 April 12th, 1985 in UTC. 411 1996-12-19T16:39:57-08:00 413 This represents 39 minutes and 57 seconds after the 16th hour of 414 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 415 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z 416 in UTC. 418 1990-12-31T23:59:60Z 420 This represents the leap second inserted at the end of 1990. 422 1990-12-31T15:59:60-08:00 424 This represents the same leap second in Pacific Standard Time, 8 425 hours behind UTC. 427 1937-01-01T12:00:27.87+00:20 429 This represents the same instant of time as noon, January 1, 1937, 430 Netherlands time. Standard time in the Netherlands was exactly 19 431 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 432 1937-06-30. This time zone cannot be represented exactly using the 433 HH:MM format, and this timestamp uses the closest representable UTC 434 offset. 436 6. Acknowledgements 438 The following people provided helpful advice for an earlier 439 incarnation of this document: Ned Freed, Neal McBurnett, David 440 Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due 441 to participants of the IETF Calendaring/Scheduling working group 442 mailing list, and participants of the time zone mailing list. 444 The following reviewers contributed helpful suggestions for the 445 present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn. 446 Paul Eggert provided many careful observations regarding the 447 subtleties of leap seconds and time zone offsets. 449 7. References 451 [Zeller] Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol. 452 9, Nov 1886. 454 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet 455 Text Messages", RFC 822, August 1982. 457 [IMAIL-UPDATE] 458 Resnick, P., "Internet Message Format", RFC 2822, April 459 2001. 461 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 462 Specifications: ABNF", RFC 2234, November 1997. 464 [ISO8601] "Data elements and interchange formats -- Information 465 interchange -- Representation of dates and times", ISO 466 8601:1988(E), International Organization for 467 Standardization, June, 1988. 469 [ISO8601:2000] 470 "Data elements and interchange formats -- Information 471 interchange -- Representation of dates and times", ISO 472 8601:2000, International Organization for 473 Standardization, December, 2000. 475 [HOST-REQ] Braden, R., "Requirements for Internet Hosts -- 476 Application and Support", RFC 1123, Internet Engineering 477 Task Force, October 1989. 479 [IERS] International Earth Rotation Service Bulletins, 480 . 482 [NTP] Mills, D., "Network Time Protocol (Version 3) 483 Specification, Implementation and Analysis", RFC 1305, 484 University of Delaware, March 1992. 486 [ITU-R-TF] International Telecommunication Union Recommendations for 487 Time Signals and Frequency Standards Emissions. 488 490 8. Security Considerations 492 Since the local time zone of a site may be useful for determining a 493 time when systems are less likely to be monitored and might be more 494 susceptible to a security probe, some sites may wish to emit times in 495 UTC only. Others might consider this to be loss of useful 496 functionality at the hands of paranoia. 498 9. Authors' Addresses 500 Chris Newman 501 Sun Microsystems 502 1050 Lakes Drive, Suite 250 503 West Covina, CA 91790 USA 505 Email: cnewman@iplanet.com 507 Graham Klyne (editor, this revision) 508 Baltimore Technologies - Content Security Group 509 1310 Waterside 510 Arlington Business Park 511 Theale 512 Reading, RG7 4SA 513 United Kingdom. 514 Telephone: +44 118 903 8000 515 Facsimile: +44 118 903 9000 516 E-mail: GK@ACM.ORG 518 Appendix A. ISO 8601 Collected ABNF 520 This information is based on the 1988 version of ISO 8601. There may 521 be some changes in the 2000 revision. 523 ISO 8601 does not specify a formal grammar for the date and time 524 formats it defines. The following is an attempt to create a formal 525 grammar from ISO 8601. This is informational only and may contain 526 errors. ISO 8601 remains the authoritative reference. 528 Note that due to ambiguities in ISO 8601, some interpretations had to 529 be made. First, ISO 8601 is not clear if mixtures of basic and 530 extended format are permissible. This grammar permits mixtures. ISO 531 8601 is not clear on whether an hour of 24 is permissible only if 532 minutes and seconds are 0. This assumes that an hour of 24 is 533 permissible in any context. Restrictions on date-mday in section 5.7 534 apply. ISO 8601 states that the "T" may be omitted under some 535 circumstances. This grammar requires the "T" to avoid ambiguity. 537 ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction 538 be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 539 gives examples where the decimal fractions are not preceded by a "0". 540 This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is 541 in error. 543 date-century = 2DIGIT ; 00-99 544 date-decade = DIGIT ; 0-9 545 date-subdecade = DIGIT ; 0-9 546 date-year = date-decade date-subdecade 547 date-fullyear = date-century date-year 548 date-month = 2DIGIT ; 01-12 549 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday 550 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 551 date-yday = 3DIGIT ; 001-365, 001-366 based on year 552 date-week = 2DIGIT ; 01-52, 01-53 based on year 554 datepart-fullyear = [date-century] date-year ["-"] 555 datepart-ptyear = "-" [date-subdecade ["-"]] 556 datepart-wkyear = datepart-ptyear / datepart-fullyear 558 dateopt-century = "-" / date-century 559 dateopt-fullyear = "-" / datepart-fullyear 560 dateopt-year = "-" / (date-year ["-"]) 561 dateopt-month = "-" / (date-month ["-"]) 562 dateopt-week = "-" / (date-week ["-"]) 564 datespec-full = datepart-fullyear date-month ["-"] date-mday 565 datespec-year = date-century / dateopt-century date-year 566 datespec-month = "-" dateopt-year date-month [["-"] date-mday] 567 datespec-mday = "--" dateopt-month date-mday 568 datespec-week = datepart-wkyear "W" 569 (date-week / dateopt-week date-wday) 570 datespec-wday = "---" date-wday 571 datespec-yday = dateopt-fullyear date-yday 573 date = datespec-full / datespec-year / datespec-month / 574 datespec-mday / datespec-week / datespec-wday / datespec-yday 576 Time: 578 time-hour = 2DIGIT ; 00-24 579 time-minute = 2DIGIT ; 00-59 580 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap-second rules 581 time-fraction = ("," / ".") 1*DIGIT 582 time-numoffset = ("+" / "-") time-hour [[":"] time-minute] 583 time-zone = "Z" / time-numoffset 585 timeopt-hour = "-" / (time-hour [":"]) 586 timeopt-minute = "-" / (time-minute [":"]) 588 timespec-hour = time-hour [[":"] time-minute [[":"] time-second]] 589 timespec-minute = timeopt-hour time-minute [[":"] time-second] 590 timespec-second = "-" timeopt-minute time-second 591 timespec-base = timespec-hour / timespec-minute / timespec-second 593 time = timespec-base [time-fraction] [time-zone] 595 iso-date-time = date "T" time 597 Durations: 599 dur-second = 1*DIGIT "S" 600 dur-minute = 1*DIGIT "M" [dur-second] 601 dur-hour = 1*DIGIT "H" [dur-minute] 602 dur-time = "T" (dur-hour / dur-minute / dur-second) 603 dur-day = 1*DIGIT "D" 604 dur-week = 1*DIGIT "W" 605 dur-month = 1*DIGIT "M" [dur-day] 606 dur-year = 1*DIGIT "Y" [dur-month] 607 dur-date = (dur-day / dur-month / dur-year) [dur-time] 609 duration = "P" (dur-date / dur-time / dur-week) 611 Periods: 613 period-explicit = date-time "/" date-time 614 period-start = date-time "/" duration 615 period-end = duration "/" date-time 617 period = period-explicit / period-start / period-end 619 Appendix B. Day of the Week 621 The following is a sample C subroutine loosely based on Zeller's 622 Congruence [Zeller] which may be used to obtain the day of the week 623 for dates on or after 0000-02-01: 625 char *day_of_week(int day, int month, int year) 626 { 627 int cent; 628 char *dayofweek[] = { 629 "Sunday", "Monday", "Tuesday", "Wednesday", 630 "Thursday", "Friday", "Saturday" 631 }; 633 /* adjust months so February is the last one */ 634 month -= 2; 635 if (month < 1) { 636 month += 12; 637 --year; 638 } 639 /* split by century */ 640 cent = year / 100; 641 year %= 100; 642 return (dayofweek[((26 * month - 2) / 10 + day + year 643 + year / 4 + cent / 4 - 2 * cent) % 7]); 644 } 646 Appendix C. Leap Years 648 Here is a sample C subroutine to calculate if a year is a leap year: 650 /* This returns non-zero if year is a leap year. Must use 4 digit year. 651 */ 652 int leap_year(int year) 653 { 654 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 655 } 657 Appendix D. Leap Seconds 659 Information about leap seconds can be found at: 660 . In particular, it notes 661 that: 663 The decision to introduce a leap second in UTC is the 664 responsibility of the International Earth Rotation Service (IERS). 665 According to the CCIR Recommendation, first preference is given to 666 the opportunities at the end of December and June, and second 667 preference to those at the end of March and September. 669 When required, insertion of a leap second occurs as an extra second 670 at the end of a day in UTC, represented by a timestamp of the form 671 YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all 672 time zones, so that time zone relationships are not affected. See 673 section 5.8 for some examples of leap second times. 675 The following table is an excerpt from the table maintained by the 676 United States Naval Observatory. The source data is located at: 678 680 This table shows the date of the leap second, and the difference 681 between the time standard TAI (which isn't adjusted by leap seconds) 682 and UTC after that leap second. 684 UTC Date TAI - UTC After Leap Second 685 -------- --------------------------- 686 1972-06-30 11 687 1972-12-31 12 688 1973-12-31 13 689 1974-12-31 14 690 1975-12-31 15 691 1976-12-31 16 692 1977-12-31 17 693 1978-12-31 18 694 1979-12-31 19 695 1981-06-30 20 696 1982-06-30 21 697 1983-06-30 22 698 1985-06-30 23 699 1987-12-31 24 700 1989-12-31 25 701 1990-12-31 26 702 1992-06-30 27 703 1993-06-30 28 704 1994-06-30 29 705 1995-12-31 30 706 1997-06-30 31 707 1998-12-31 32 709 Appendix E. Amendment history 711 00a 30-Mar-2001 This document version created from Chris Newman's 712 original 'draft-ietf-impp-datetime-00.txt'. Material 713 relating to future times (schedule events) and time zone 714 names has been removed. Added introductory text setting 715 the scope for this document. Various small editorial 716 changes. 718 00b 03-Apr-2001 Added reference [ABNF], and updated citations. Added 719 comment about possible use of space-separated date/time 720 fields. Added comment about possible use of lower case 721 "t" and "z" in syntax. Corrected leap-second examples 722 and noted that leap second point is offset by time zone. 724 01a 06-Apr-2001 Updated author affiliation and contact details. Udated 725 leap-second table. 727 01b 10-May-2001 Clarified provenance of (non-normative) information in 728 appendix A. 730 02a 11-May-2001 Reference updated email specification (RFC2822). 732 02b 14-May-2001 Fix up some detailed information concerning leap 733 seconds. Include text describing timestamps for times 734 before introduction of UTC. Caution against the use of 735 future timestamps using leap seconds. Correction to 736 day-of-week sample code, and note restriction on 737 applicability. Various editorial corrections. 739 03a 23-May-2001 Editorial fixes. Minor clarification of leap seconds. 741 03b 24-May-2001 More clarification of leap seconds and time zones. 743 03c 25-May-2001 More minor editorial fixes. 745 04a 03-Jul-2001 Fix off-by-one error in Netherlands example. 747 Full copyright statement 749 Copyright (C) The Internet Society 2001. All Rights Reserved. 751 This document and translations of it may be copied and furnished to 752 others, and derivative works that comment on or otherwise explain it 753 or assist in its implementation may be prepared, copied, published 754 and distributed, in whole or in part, without restriction of any 755 kind, provided that the above copyright notice and this paragraph are 756 included on all such copies and derivative works. However, this 757 document itself may not be modified in any way, such as by removing 758 the copyright notice or references to the Internet Society or other 759 Internet organizations, except as needed for the purpose of 760 developing Internet standards in which case the procedures for 761 copyrights defined in the Internet Standards process must be 762 followed, or as required to translate it into languages other than 763 English. 765 The limited permissions granted above are perpetual and will not be 766 revoked by the Internet Society or its successors or assigns. 768 This document and the information contained herein is provided on an 769 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 770 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 771 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 772 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 773 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.