idnits 2.17.1 draft-ietf-impp-datetime-00.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 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages -- Found 16 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 8 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 151: '...ternet Protocols MUST generate four di...' RFC 2119 keyword, line 172: '...ternet protocols MUST be fully qualifi...' RFC 2119 keyword, line 190: '... offsets are now REQUIRED in Internet ...' RFC 2119 keyword, line 203: '... MAY also be used in the Email Date/...' RFC 2119 keyword, line 216: '...ith other Internet systems, MUST use a...' (3 more instances...) 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 April 2001) is 8425 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-R-TF' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Newman, Innosoft 2 Internet Draft G. Klyne, Baltimore Technologies 3 3 April 2001 4 Expires: September 2001 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 make 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 0AD 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 Date and time expressions indicate an instant in time. 107 Description of time periods, or intervals, is not covered here. 109 2. Definitions 111 UTC Coordinated Universal Time as maintained by the Bureau 112 Internaational des Poids et Mesures (BIPM). 114 second A basic unit of measurement of time in the International 115 System of Units. It is defined as the duration of 116 9,192,631,770 cycles of microwave light absorbed or 117 emitted by the hyperfine transition of cesium-133 atoms 118 in their ground state undisturbed by external fields. 120 minute A period of time of 60 seconds. 122 hour A period of time of 60 minutes. 124 day A period of time of 24 hours. 126 leap year In the Gregorian calendar, a year which has 366 days. A 127 leap year is a year whose number is divisible by four an 128 integral number of times, except that if it is a 129 centennial year it shall be divisible by four hundred an 130 integral number of times. 132 ABNF Augmented Backus-Naur Form, a format used to represent 133 permissible strings in a protocol or language, as defined 134 in [ABNF]. 136 Email Date/Time Format 137 The date/time format used by Internet Mail as defined by 138 RFC 822 [IMAIL] and amended by RFC 1123 [HOST-REQ]. 140 Internet Date/Time Format 141 The date format defined in section 5 of this document. 143 For more information about time scales, see Appendix E of [NTP], 144 Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF]. 146 3. Two Digit Years 148 The following requirements are to address the problems of ambiguity 149 of 2-digit years: 151 o Internet Protocols MUST generate four digit years in dates. 153 o The use of 2-digit years is deprecated. If a 2-digit year is 154 received, it should be accepted ONLY if an incorrect 155 interpretation will not cause a protocol or processing failure 156 (e.g. if used only for logging or tracing purposes). 158 o It is possible that a program using two digit years will represent 159 years after 1999 as three digits. This occurs if the program 160 simply subtracts 1900 from the year and doesn't check the number 161 of digits. Programs wishing to robustly deal with dates generated 162 by such broken software may add 1900 to three digit years. 164 o It is possible that a program using two digit years will represent 165 years after 1999 as ":0", ":1", ... ":9", ";0", ... This occurs 166 if the program simply subtracts 1900 from the year and adds the 167 decade to the US-ASCII character zero. Programs wishing to 168 robustly deal with dates generated by such broken software should 169 detect non-numeric decades and interpret appropriately. 171 The problems with two digit years amply demonstrate why all dates and 172 times used in Internet protocols MUST be fully qualified. 174 4. Local Time 176 4.1. Coordinated Universal Time (UTC) 178 Because the daylight rules for local timezones are so convoluted and 179 can change based on local law at unpredictable times, true 180 interoperability is best achieved by using Coordinated Universal Time 181 (UTC). This specification does not cater to local timezone rules. 183 4.2. Local Offsets 185 The offset between local time and UTC is often useful information. 186 For example, in electronic mail [IMAIL] the local offset provides a 187 useful heuristic to determine the probability of a prompt response. 188 Attempts to label local offsets with alphabetic strings have resulted 189 in poor interoperability in the past [IMAIL], [HOST-REQ]. Therefore 190 numeric offsets are now REQUIRED in Internet Mail Date/Time Format. 192 Numeric offsets are calculated as "local time minus UTC". So the 193 equivalent time in UTC can be determined by subtracting the offset 194 from the local time. For example, 18:50:00-04:00 is the same time as 195 22:58:00Z. 197 4.3. Unknown Local Offset Convention 199 If the time in UTC is known, but the offset to local time is unknown, 200 this can be represented with an offset of "-00:00". This differs 201 semanticly from an offset of "Z" which implies that UTC is the 202 preferred reference point for the specified time. This convention 203 MAY also be used in the Email Date/Time Format. 205 4.4. Unqualified Local Time 207 A number of devices currently connected to the Internet run their 208 internal clocks in local time and are unaware of UTC. While the 209 Internet does have a tradition of accepting reality when creating 210 specifications, this should not be done at the expense of 211 interoperability. Since interpretation of an unqualified local 212 timezone will fail in approximately 23/24 of the globe, the 213 interoperability problems of unqualified local time are deemed 214 unacceptable for the Internet. Systems that are configured with a 215 local time, are unaware of the corresponding UTC offset, and depend 216 on time synchronization with other Internet systems, MUST use a 217 mechanism that ensures correct synchronization with UTC. Some 218 suitable mechanisms are: 220 o Use Network Time Protocol [NTP] to obtain the time in UTC. 222 o Use another host in the same local timezone as a gateway to the 223 Internet. This host MUST correct unqualified local times before 224 they are transmitted to other hosts. 226 o Prompt the user for the local timezone and daylight savings 227 settings. 229 5. Date and Time format 231 This section discusses desirable qualities of date and time formats 232 and defines a profile of ISO 8601 for use in Internet protocols. 234 5.1. Ordering 236 If date and time components are ordered from least precise to most 237 precise, then a useful property is achieved. Assuming that the 238 timezones of the dates and times are the same (e.g. all in UTC), then 239 the date and time strings may be sorted as strings (e.g. using the 240 strcmp() function in C) and a time-ordered sequence will result. The 241 presence of optional punctuation would violate this characteristic. 243 5.2. Human Readability 245 Human readability has proved to be a valuable feature of Internet 246 protocols. Human readable protocols greatly reduce the costs of 247 debugging since telnet often suffices as a test client and network 248 analysers need not be modified with knowledge of the protocol. On 249 the other hand, human readability sometimes results in 250 interoperability problems. For example, the date format "10/11/1996" 251 is completely unsuitable for global interchange because it is 252 interpreted differently in different countries. In addition, the 253 date format in [IMAIL] has resulted in interoperability problems when 254 people assumed any text string was permitted and translated the three 255 letter abbreviations to other languages or substituted date formats 256 which were easier to generate (e.g. the format used by the C function 257 ctime). For this reason, a balance must be struck between human 258 readability and interoperability. 260 Because no date and time format is readable according to the 261 conventions of all countries, Internet clients SHOULD be prepared to 262 transform dates into a display format suitable for the locality. 263 This may include translating UTC to local time. 265 5.3. Rarely Used Options 267 A format which includes rarely used options is likely to cause 268 interoperability problems. This is because rarely used options are 269 less likely to be used in alpha or beta testing, so bugs in parsing 270 are less likely to be discovered. Rarely used options should be made 271 mandatory or omitted for the sake of interoperability whenever 272 possible. 274 The format defined below includes only one rarely used option: 275 fractions of a second. It is expected that this will be used only by 276 applications which require strict ordering of date/time stamps or 277 which have an unusual precision requirement. 279 5.4. Redundant Information 281 If a date/time format includes redundant information, that introduces 282 the possibility that the redunant information will not correlate. 283 For example, including the day of the week in a date/time format 284 introduces the possibility that the day of week is incorrect but the 285 date is correct, or vice versa. Since it is not difficult to compute 286 the day of week from a date (see Appendix B), the day of week should 287 not be included in a date/time format. 289 5.5. Simplicity 291 The complete set of date and time formats specified in ISO 8601 292 [ISO8601] is quite complex in an attempt to provide multiple 293 representations and partial representations. Appendix A contains an 294 attempt to translate the complete syntax of ISO 8601 into ABNF. 295 Internet protocols have somewhat different requirements and 296 simplicity has proved to be an important characteristic. In 297 addition, Internet protocols usually need complete specification of 298 data in order to achieve true interoperability. Therefore, the 299 complete grammar for ISO 8601 is deemed too complex for most Internet 300 protocols. 302 The following section defines a profile of ISO 8601 for use on the 303 Internet. It is a conformant subset of the ISO 8601 extended format. 304 Simplicity is achieved by making most fields and punctuation 305 mandatory. 307 5.6. Internet Date/Time Format 309 The following profile of ISO 8601 [ISO8601] dates SHOULD be used in 310 new protocols on the Internet. This is specified using the syntax 311 description notation defined in [ABNF]. 313 date-fullyear = 4DIGIT 314 date-month = 2DIGIT ; 01-12 315 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 316 time-hour = 2DIGIT ; 00-23 317 time-minute = 2DIGIT ; 00-59 318 time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules 319 time-secfrac = "." 1*DIGIT 320 time-numoffset = ("+" / "-") time-hour ":" time-minute 321 time-offset = "Z" / time-numoffset 323 partial-time = time-hour ":" time-minute ":" time-second 324 [time-secfrac] 325 full-date = date-fullyear "-" date-month "-" date-mday 326 full-time = partial-time time-offset 328 date-time = full-date "T" full-time 330 NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in 331 this syntax may alternatively be lower case "t" or "z" 332 respectively. 334 NOTE: ISO 8601 defines date and time separated by "T". 335 Applications using this syntax may choose, for the sake of 336 readability, to specify a full-date and full-time separated by 337 (say) a space character. 339 5.7. Restrictions 341 The grammar element date-mday represents the day number within the 342 current month. The maximum value varies based on the month and year 343 as follows: 345 Month Number Month/Year Maximum value of date-mday 346 ------------ ---------- -------------------------- 347 01 January 31 348 02 February, normal 28 349 02 February, leap year 29 350 03 March 31 351 04 April 30 352 05 May 31 353 06 June 30 354 07 July 31 355 08 August 31 356 09 September 30 357 10 October 31 358 11 November 30 359 12 December 31 361 Appendix C contains sample C code to determine if a year is a leap 362 year. 364 The grammar element time-second may have the value "60" at the end of 365 June (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z) if 366 there is a leap second at that time (see Appendix D for a table of 367 leap seconds). At all other times the maximum value of time-second 368 is "59". Further, in timezones other than "Z", the leap second point 369 is shifted by the zone offset (so it happens at the same instant 370 around the globe). 372 Although ISO 8601 permits the hour to be "24", this profile of ISO 373 8601 only allows values between "00" and "23" for the hour in order 374 to reduce confusion. 376 5.8. Examples 378 Here are three examples of Internet date/time format. 380 1985-04-12T23:20:50.52Z 382 This represents 20 minutes and 50.52 seconds after the 23rd hour of 383 April 12th, 1985 in UTC. 385 1996-12-19T16:39:57-08:00 387 This represents 39 minutes and 57 seconds after the 16th hour of 388 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 389 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z 390 in UTC. 392 1990-12-31T23:59:60Z 394 This represents the leap second inserted at the end of 1990. 396 1990-12-31T15:59:60-08:00 398 This represents the same leap second in Pacific Standard Time, 8 399 hours behind UTC. 401 6. Acknowledgements 403 The following people provided helpful advice for an earlier 404 incarnation of this document: Ned Freed, Neal McBurnett, David 405 Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due 406 to participants of the IETF Calendaring/Scheduling working group 407 mailing list, and participants of the timezone mailing list. 409 7. References 411 [Zeller] Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol. 412 9, Nov 1886. 414 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet 415 Text Messages", RFC 822, August 1982. 417 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 418 Specifications: ABNF", RFC 2234, November 1997. 420 [ISO8601] "Data elements and interchange formats -- Information 421 interchange -- Representation of dates and times", ISO 422 8601:1988(E), International Organization for 423 Standardization, June, 1988. 425 [HOST-REQ] Braden, R., "Requirements for Internet Hosts -- 426 Application and Support", RFC 1123, Internet Engineering 427 Task Force, October 1989. 429 [NTP] Mills, D., "Network Time Protocol (Version 3) 430 Specification, Implementation and Analysis", RFC 1305, 431 University of Delaware, March 1992. 433 [ITU-R-TF] International Telecommunication Union Recommendations for 434 Time Signals and Frequency Standards Emissions. 435 437 8. Security Considerations 439 Since the local time zone of a site may be useful for determining a 440 time when systems are less likely to be monitored and might be more 441 susceptible to a security probe, some sites may wish to emit times in 442 UTC only. Others might consider this to be loss of useful 443 functionality at the hands of paranoia. 445 9. Authors' Addresses 447 Chris Newman 448 Innosoft International, Inc. 449 1050 Lakes Drive 450 West Covina, CA 91790 USA 452 Email: chris.newman@innosoft.com 454 Graham Klyne 455 Baltimore Technologies - Content Security Group 456 1310 Waterside 457 Arlington Business Park 458 Theale 459 Reading, RG7 4SA 460 United Kingdom. 461 Telephone: +44 118 903 8000 462 Facsimile: +44 118 903 9000 463 E-mail: GK@ACM.ORG 465 Appendix A. ISO 8601 Collected ABNF 467 ISO 8601 does not specify a formal grammar for the date and time 468 formats it defines. The following is an attempt to create a formal 469 grammar from ISO 8601. This is informational only and may contain 470 errors. ISO 8601 remains the authoratative reference. 472 Note that due to ambiguities in ISO 8601, some interpretations had to 473 be made. First, ISO 8601 is not clear if mixtures of basic and 474 extended format are permissible. This grammar permits mixtures. ISO 475 8601 is not clear on whether an hour of 24 is permissible only if 476 minutes and seconds are 0. This assumes that an hour of 24 is 477 permissible in any context. Restrictions on date-mday in section 5.7 478 apply. ISO 8601 states that the "T" may be omitted under some 479 circumstances. This grammar requires the "T" to avoid ambiguity. 481 ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction 482 be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 483 gives examples where the decimal fractions are not preceeded by a 484 "0". This grammar assumes section 5.3.1.3 is correct and that Annex 485 B.2 is in error. 487 date-century = 2DIGIT ; 00-99 488 date-decade = DIGIT ; 0-9 489 date-subdecade = DIGIT ; 0-9 490 date-year = date-decade date-subdecade 491 date-fullyear = date-century date-year 492 date-month = 2DIGIT ; 01-12 493 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday 494 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 495 date-yday = 3DIGIT ; 001-365, 001-366 based on year 496 date-week = 2DIGIT ; 01-52, 01-53 based on year 498 datepart-fullyear = [date-century] date-year ["-"] 499 datepart-ptyear = "-" [date-subdecade ["-"]] 500 datepart-wkyear = datepart-ptyear / datepart-fullyear 502 dateopt-century = "-" / date-century 503 dateopt-fullyear = "-" / datepart-fullyear 504 dateopt-year = "-" / (date-year ["-"]) 505 dateopt-month = "-" / (date-month ["-"]) 506 dateopt-week = "-" / (date-week ["-"]) 508 datespec-full = datepart-fullyear date-month ["-"] date-mday 509 datespec-year = date-century / dateopt-century date-year 510 datespec-month = "-" dateopt-year date-month [["-"] date-mday] 511 datespec-mday = "--" dateopt-month date-mday 512 datespec-week = datepart-wkyear "W" 513 (date-week / dateopt-week date-wday) 514 datespec-wday = "---" date-wday 515 datespec-yday = dateopt-fullyear date-yday 517 date = datespec-full / datespec-year / datespec-month / 518 datespec-mday / datespec-week / datespec-wday / datespec-yday 520 Time: 522 time-hour = 2DIGIT ; 00-24 523 time-minute = 2DIGIT ; 00-59 524 time-second = 2DIGIT ; 00-59, 00-60 based on leap-second rules 525 time-fraction = ("," / ".") 1*DIGIT 526 time-numoffset = ("+" / "-") time-hour [[":"] time-minute] 527 time-zone = "Z" / time-numoffset 529 timeopt-hour = "-" / (time-hour [":"]) 530 timeopt-minute = "-" / (time-minute [":"]) 532 timespec-hour = time-hour [[":"] time-minute [[":"] time-second]] 533 timespec-minute = timeopt-hour time-minute [[":"] time-second] 534 timespec-second = "-" timeopt-minute time-second 535 timespec-base = timespec-hour / timespec-minute / timespec-second 537 time = timespec-base [time-fraction] [time-zone] 539 iso-date-time = date "T" time 541 Durations: 543 dur-second = 1*DIGIT "S" 544 dur-minute = 1*DIGIT "M" [dur-second] 545 dur-hour = 1*DIGIT "H" [dur-minute] 546 dur-time = "T" (dur-hour / dur-minute / dur-second) 547 dur-day = 1*DIGIT "D" 548 dur-week = 1*DIGIT "W" 549 dur-month = 1*DIGIT "M" [dur-day] 550 dur-year = 1*DIGIT "Y" [dur-month] 551 dur-date = (dur-day / dur-month / dur-year) [dur-time] 553 duration = "P" (dur-date / dur-time / dur-week) 555 Periods: 557 period-explicit = date-time "/" date-time 558 period-start = date-time "/" duration 559 period-end = duration "/" date-time 561 period = period-explicit / period-start / period-end 563 Appendix B. Day of the Week 565 The following is a sample C subroutine loosly based on Zeller's 566 Congruence [Zeller] which may be used to obtain the day of the week: 568 char *day_of_week(int day, int month, int year) 569 { 570 char *dayofweek[] = { 571 "Sunday", "Monday", "Tuesday", "Wednesday", 572 "Thursday", "Friday", "Saturday" 573 }; 575 /* adjust months so February is the last one */ 576 month -= 2; 577 if (month < 1) { 578 month += 12; 579 --year; 580 } 581 /* split by century */ 582 cent = year / 100; 583 year %= 100; 584 return (dayofweek[((26 * month - 2) / 10 + day + year 585 + year / 4 + cent / 4 - 2 * cent) % 7]); 586 } 588 Appendix C. Leap Years 590 Here is a sample C subroutine to calculate if a year is a leap year: 592 /* This returns non-zero if year is a leap year. Must use 4 digit year. 593 */ 594 int leap_year(int year) 595 { 596 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 597 } 599 Appendix D. Leap Seconds 601 This table is an excerpt from the table maintained by the United 602 States Naval Observatory. The source data is located at: 604 606 This table shows the date of the leap second, and the difference 607 between the time standard TAI (which isn't adjusted by leap seconds) 608 and UTC after that leap second. 610 UTC Date TAI - UTC After Leap Second 611 -------- --------------------------- 612 1972-06-30 11 613 1972-12-31 12 614 1973-12-31 13 615 1974-12-31 14 616 1975-12-31 15 617 1976-12-31 16 618 1977-12-31 17 619 1978-12-31 18 620 1979-12-31 19 621 1981-06-30 20 622 1982-06-30 21 623 1983-06-30 22 624 1985-06-30 23 625 1987-12-31 24 626 1989-12-31 25 627 1990-12-31 26 628 1992-06-30 27 629 1993-06-30 28 630 1994-06-30 29 631 1995-12-31 30 632 1997-06-30 31 634 Appendix E. Amendment history 636 00a 30-Mar-2001 This document version created from Chris Newman's 637 original 'draft-ietf-impp-datetime-00.txt'. Material 638 relating to future times (schedule events) and timezone 639 names has been removed. Added introductory text setting 640 the scope for this document. Various small editorial 641 changes. 643 00b 03-Apr-2001 Added reference [ABNF], and updated citations. Added 644 comment about possible use of space-separated date/time 645 fields. Added comment about possible use of lower case 646 "t" and "z" in syntax. Corrected leap-second examples 647 and noted that leap second point is offset by time zone. 649 Full copyright statement 651 Copyright (C) The Internet Society 2001. All Rights Reserved. 653 This document and translations of it may be copied and furnished to 654 others, and derivative works that comment on or otherwise explain it 655 or assist in its implementation may be prepared, copied, published 656 and distributed, in whole or in part, without restriction of any 657 kind, provided that the above copyright notice and this paragraph are 658 included on all such copies and derivative works. However, this 659 document itself may not be modified in any way, such as by removing 660 the copyright notice or references to the Internet Society or other 661 Internet organizations, except as needed for the purpose of 662 developing Internet standards in which case the procedures for 663 copyrights defined in the Internet Standards process must be 664 followed, or as required to translate it into languages other than 665 English. 667 The limited permissions granted above are perpetual and will not be 668 revoked by the Internet Society or its successors or assigns. 670 This document and the information contained herein is provided on an 671 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 672 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 673 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 674 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 675 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.