idnits 2.17.1 draft-newman-datetime-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 10 instances of too long lines in the document, the longest one being 7 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 117: '...ternet Protocols MUST generate four di...' RFC 2119 keyword, line 119: '... is received, the values 00-49 MUST be...' RFC 2119 keyword, line 121: '... values 50-99 MUST be interpreted a...' RFC 2119 keyword, line 146: '...ternet protocols MUST be fully qualifi...' RFC 2119 keyword, line 164: '... offsets are now REQUIRED in Internet ...' (11 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 (January 1997) is 9962 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) -- 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: 14 errors (**), 0 flaws (~~), 1 warning (==), 6 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-01.txt January 1997 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 using the 42 Gregorian calendar. 44 Changes from draft -00: 45 * added some more definitions and references (fixed NTP reference) 46 * language clarifications 47 * include rules for day of month and leap seconds 48 * disallow hour of 24 49 * add registry of named timezones and local time format 50 * use . instead of , for fractions of second 51 * removed references to AM/PM 52 * simplified appendix B program 53 * added appendix C program to calculate leap year 55 Controversial in last draft, but unchanged: 56 * use of "T" as date/time separator. Proposal is to use " " instead, 57 but my reading of ISO 8601 does not permit that. 58 * suggestion to make minutes offset from UTC optional. 59 * interpretation of 2 digit years 61 Open issues: 62 * See controversial issues above. More comment is welcome. 63 * Are more definitions needed? 64 * A number of the timezones in the initial registry list are 65 duplicates for future times. I already removed the Indiana county 66 ones since they all duplicate Indianapolis for future times. 67 * Need reference to good article demonstrating year 2000 problems. 68 * Need commentary on registry and to set up address for registry. 69 * Will add appendix D, E with sample POSIX generation/parsing code 70 for section 5.6. Markus Kuhn is working on code. 72 2. Definitions 74 UTC Coordinated Universal Time as maintained by the Bureau 75 Internaational de l'Heure (International Time Bureau). 77 second A basic unit of measurement of time in the 78 International System of Units. 80 minute A period of time of 60 seconds. 82 hour A period of time of 60 minutes. 84 day A period of time of 24 hours. 86 leap year In the Gregorian calendar, a year which has 366 days. 87 A leap year is a year whose number is divisible by four 88 an integral number of times, except that if it is a 89 centennial year it shall be divisible by four hundred 90 an integral number of times. 92 ABNF Augmented Backus-Naur Form, a format used to represent 93 permissible strings in a protocol or language, as 94 defined in [IMAIL]. 96 Email Date/Time Format 97 The date/time format used by Internet Mail as defined 98 by RFC 822 [IMAIL] and amended by RFC 1123 [HOST-REQ]. 100 Internet Date/Time Format 101 The date format defined in section 5 of this document. 103 For more information about time scales, see Appendix E of [NTP], 104 Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R- 105 TF]. 107 3. Two Digit Years 109 Two digit years are expected to cause great expense to many as the 110 year 2000 approaches. Many existing computer programs simply add 111 or subtract 1900 from a two digit year. Such programs will clearly 112 stop functioning on the year 2000 and will have to be upgraded, 113 possibly at great expense [XXX - ref to article on IRS year 2000 114 problems would be cool]. The following requirements are made of 115 Internet protocols to address this problem: 117 o Internet Protocols MUST generate four digit years in dates. 119 o If a two digit year is received, the values 00-49 MUST be 120 interpreted as referring to the 21st century (add 2000) and the 121 values 50-99 MUST be interpreted as referring to the 20th 122 century (add 1900). While different interpretations may result 123 in a few more years of 2-digit usability for some applications, 124 it is believed that a single interpretation for two digit years 125 in all Internet protocols will result in better 126 interoperability. In addition, it is reasonable to expect all 127 Internet Protocols using 2 digit dates to be upgraded by the 128 year 2050. 130 o It is possible that a program using two digit years will 131 represent years after 1999 as three digits. This occurs if the 132 program simply subtracts 1900 from the year and doesn't check 133 the number of digits. Programs wishing to robustly deal with 134 dates generated by such broken software may add 1900 to three 135 digit years. 137 o It is possible that a program using two digit years will 138 represent years after 1999 as ":0", ":1", ... ":9", ";0", ... 139 This occurs if the program simply subtracts 1900 from the year 140 and adds the decade to the US-ASCII character zero. Programs 141 wishing to robustly deal with dates generated by such broken 142 software should detect non-numeric decades and interpret 143 appropriately. 145 The problems with two digit years amply demonstrate why all dates 146 and times used in Internet protocols MUST be fully qualified. 148 4. Local Time 150 4.1. Coordinated Universal Time (UTC) 152 Because the daylight rules for local timezones are so convoluted 153 and can change based on local law at unpredictable times, true 154 interoperability is best achieved by using Coordinated Universal 155 Time (UTC). 157 4.2. Local Offsets 159 The offset between local time and UTC is often useful information. 160 For example, in electronic mail [IMAIL] the local offset provides a 161 useful heuristic to determine the probability of a prompt response. 162 Attempts to label local offsets with alphabetic strings have 163 resulted in poor interoperability in the past [IMAIL], [HOST-REQ]. 164 Therefore numeric offsets are now REQUIRED in Internet Mail 165 Date/Time Format. 167 Numeric offsets are calculated as "local time minus UTC". So the 168 equivalent time in UTC can be determined by subtracting the offset 169 from the local time. For example, 18:50:00-04:00 is the same time 170 as 22:58:00Z. 172 4.3. Unknown Local Offset Convention 174 If the time in UTC is known, but the offset to local time is 175 unknown, this can be represented with an offset of "-00:00". This 176 differs semanticly from an offset of "Z" which implies that UTC is 177 the preferred reference point for the specified time. This 178 convention MAY also be used in the Email Date/Time Format. 180 4.4. Unqualified Local Time 182 A number of devices currently connected to the Internet run their 183 internal clocks in local time and are unaware of UTC. While the 184 Internet does have a tradition of accepting reality when creating 185 specifications, this should not be done at the expense of 186 interoperability. Since interpretation of an unqualified local 187 timezone will fail in approximately 23/24 of the globe, the 188 interoperability problems of unqualified local time are deemed 189 unacceptable for the Internet. Devices which are unaware of the 190 time in UTC MUST use one of the following techniques when 191 communicating on the Internet: 193 o Use Network Time Protocol [NTP] to obtain the time in UTC. 195 o Use another host in the same local timezone as a gateway to the 196 Internet. This host MUST correct unqualified local times before 197 they are transmitted to other hosts. 199 o Prompt the user for the local timezone and daylight savings 200 settings. 202 5. Date and Time formats 204 This section discusses desirable qualities of date and time formats 205 and defines a profile of ISO 8601 for use in new Internet 206 protocols. Email Date/Time Format lacks many of these 207 characteristics and its use in new protocols is discouraged. 209 5.1. Ordering 211 If date and time components are ordered from least precise to most 212 precise, then a useful property is achieved. Assuming that the 213 timezones of the dates and times are the same (e.g. all in UTC), 214 then the date and time strings may be sorted as strings (e.g. using 215 the strcmp() function in C) and a time-ordered sequence will 216 result. The presence of optional punctuation would violate this 217 characteristic. 219 5.2. Human Readability 221 Human readability has proved to be a valuable feature of Internet 222 protocols. Human readable protocols greatly reduce the costs of 223 debugging since telnet often suffices as a test client and network 224 analysers need not be modified with knowledge of the protocol. On 225 the other hand, human readability sometimes results in 226 interoperability problems. For example, the date format 227 "10/11/1996" is completely unsuitable for global interchange 228 because it is interpreted differently in different countries. In 229 addition, the date format in [IMAIL] has resulted in 230 interoperability problems when people assumed any text string was 231 permitted and translated the three letter abbreviations to other 232 languages or substituted date formats which were easier to generate 233 (e.g. the format used by the C function ctime). For this reason, a 234 balance must be struck between human readability and 235 interoperability. 237 Because no date and time format is readable according to the 238 conventions of all countries, Internet clients SHOULD be prepared 239 to transform dates into a display format suitable for the locality. 240 This may include translating UTC to local time. 242 5.3. Rarely Used Options 244 A format which includes rarely used options is likely to cause 245 interoperability problems. This is because rarely used options are 246 less likely to be used in alpha or beta testing, so bugs in parsing 247 are less likely to be discovered. Rarely used options should be 248 made mandatory or omitted for the sake of interoperability whenever 249 possible. 251 The format defined below includes only one rarely used option: 252 fractions of a second. It is expected that this will be used only 253 by applications which require strict ordering of date/time stamps 254 or which have an unusual precision requirement. 256 5.4. Redundant Information 258 If a date/time format includes redundant information, that 259 introduces the possibility that the redunant information will not 260 correlate. For example, including the day of the week in a 261 date/time format introduces the possibility that the day of week is 262 incorrect but the date is correct, or vice versa. Since it is not 263 difficult to compute the day of week from a date (see Appendix B), 264 the day of week should not be included in a date/time format. 266 5.5. Simplicity 268 The complete set of date and time formats specified in ISO 8601 269 [ISO8601] is quite complex in an attempt to provide multiple 270 representations and partial representations. Appendix A contains 271 an attempt to translate the complete syntax of ISO 8601 into ABNF 272 as defined in [IMAIL]. Internet protocols have somewhat different 273 requirements and simplicity has proved to be an important 274 characteristic. In addition, Internet protocols usually need 275 complete specification of data in order to achieve true 276 interoperability. Therefore, the complete grammar for ISO 8601 is 277 deemed too complex for most Internet protocols. 279 The following section defines a profile of ISO 8601 for use on the 280 Internet. It is a conformant subset of the ISO 8601 extended 281 format. Simplicity is achieved by making most fields and 282 punctuation mandatory. 284 5.6. Internet Date/Time Format 286 The following profile of ISO 8601 [ISO8601] dates SHOULD be used in 287 new protocols on the Internet. This is specified using ABNF as 288 defined in [IMAIL]. 290 date-fullyear = 4DIGIT 291 date-month = 2DIGIT ; 01-12 292 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 293 time-hour = 2DIGIT ; 00-23 294 time-minute = 2DIGIT ; 00-59 295 time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules 296 time-secfrac = "." 1*DIGIT 297 time-numoffset = ("+" / "-") time-hour ":" time-minute 298 time-offset = "Z" / time-numoffset 300 partial-time = time-hour ":" time-minute ":" time-second 301 [time-secfrac] 302 full-date = date-fullyear "-" date-month "-" date-mday 303 full-time = partial-time time-offset 305 date-time = full-date "T" full-time 307 5.7. Restrictions 309 The grammar element date-mday represents the day number within the 310 current month. The maximum value varies based on the month and 311 year as follows: 313 Month Number Month/Year Maximum value of date-mday 314 ------------ ---------- -------------------------- 315 01 January 31 316 02 February, normal 28 317 02 February, leap year 29 318 03 March 31 319 04 April 30 320 05 May 31 321 06 June 30 322 07 July 31 323 08 August 31 324 09 September 30 325 10 October 31 326 11 November 30 327 12 December 31 329 Appendix C contains sample C code to determine if a year is a leap 330 year. 332 The grammar element time-second may have the value "60" at the end 333 of June (XXXX-06-30T23:59:60) or December (XXXX-12-31T23:59:60). 334 At all other times the maximum value of time-second is "59". 336 Although ISO 8601 permits the hour to be "24", this profile of ISO 337 8601 only allows values between "00" and "23" for the hour in order 338 to reduce confusion. 340 5.8. Examples 342 Here are three examples of Internet date/time format. 344 1985-04-12T23:20:50.52Z 346 This represents 20 minutes and 50.52 seconds after the 23rd hour of 347 April 12th, 1985 in UTC. 349 1996-12-19T16:39:57-08:00 351 This represents 39 minutes and 57 seconds after the 16th hour of 352 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 353 Standard Time). Note that this is equivalent to 1996-12- 354 20T00:39:57Z in UTC. 356 1990-12-31T23:59:60Z 358 This represents the leap second insertted at the end of 1990. 360 6. Future Events in Local Time 362 Some applications (e.g. calendaring) require the representation of 363 repeating or future dates in local time. Because the conversion 364 rules between UTC and local time may change by season and political 365 whim, it is necessary to label the local time zone with a standard 366 label so that if new conversion rules are issued the interpretation 367 of the time relative to UTC can be corrected. For this reason, an 368 IANA registry of timezone names which may be used to represent 369 future dates is necessary. 371 6.1. Problems Too Hard to Solve 373 Since local timezone rules are set by local governments, the only 374 authoratative reference for such rules is those governments, most 375 of which do not currently provide their rules on line in a computer 376 parsible format. In addition, local timezones were historically 377 set by cities and towns, so attempting to exhaustively enumerate 378 all historical timezones for use in representing past dates is not 379 practical. Attempting to predict where new timezones will be 380 created as a subset of the area covered by an old timezone is also 381 a hopeless prospect. 383 Therefore the only formal part of the registry will be names for a 384 minimal set of modern timezones. As a convenience, the registry 385 will also include the base UTC offset and daylight savings rules 386 (if determinable) at the time of registration. Because the UTC 387 offset and rules may changed by other bodies, they will not be 388 considered an authoratative part of the registry. 390 6.2. Prior Art 392 An informal collection of timezone information is currently being 393 maintained by volunteer Internet participants. The current 394 location of this information is: 396 398 This is valuable work, and is used in some operating systems. The 399 initial set of timezone names for the IANA registry is a subset of 400 the names collected by this effort. 402 6.3. Legal Characters in Timezone Names 404 Only the US-ASCII characters A-Z, a-z, 0-9, "-", "_" and "/" are 405 legal in timezone names. The basic format is the name of a 406 continent or ocean followed by a "/" followed by the name of a city 407 or political entity. A political entity may be followed by a "/" 408 and a subentity if necessary. Timezone names SHOULD use the 409 standard case in the registry, but MUST be interpreted in a case 410 insensitive manner. New timezone names SHOULD use "-" rather than 411 "_", as the latter is difficult to see in some output contexts. 413 6.4. Template for IANA Registration of Timezone Names 415 To: timezone@XXX 416 Subject: Timezone Name Registration 418 Timezone Name: 420 ISO 3166 2-character country code: 422 Description: 424 6.5. Proceedure for IANA Registration of Timezone Names 426 The IESG is responsible for appointing a reviewer of Timezone 427 Names. The job of this reviewer is to verify that the new timezone 428 name has unique UTC rules, is likely to be used, fits the rules in 429 section 6.3 and does not conflict unnecessarily with prior art 430 (especially that mentioned in section 6.2). Within two weeks of 431 posting, the reviewer must take one of the following actions: 433 (1) Pass the registration proposal to IANA. 435 (2) Reject the registration proposal. 437 (3) Recommend alterations to the registration proposal likely to make 438 it acceptable. 440 In order to assist the reviewer, the address timezone@XXX will be a 441 public mailing list where registration proposals may be discussed. 442 Subscription and unsubscription requests may be sent to timezone- 443 request@XXX. 445 6.6. Initial List of IANA Timezone Names 447 The following list will serve as the initial list of IANA Timezone 448 Names. This list was generated from the archive mentioned in 449 section 6.2. Some of these timezone names (especially within the 450 same country) are redundant for future dates, but compatibility 451 with the timezone names in the databases discussed section 6.2. is 452 useful. 454 Timezone Name Country 455 ------------- ------- 456 Europe/Andorra AD 457 Asia/Dubai AE 458 Asia/Kabul AF 459 America/Antigua AG 460 America/Anguilla AI 461 Europe/Tirane AL 462 Asia/Yerevan AM 463 America/Curacao AN 464 Africa/Luanda AO 465 Antarctica/Casey AQ 466 Antarctica/DumontDUrville AQ 467 Antarctica/Mawson AQ 468 Antarctica/McMurdo AQ 469 Antarctica/Palmer AQ 470 Antarctica/South_Pole AQ 471 America/Buenos_Aires AR 472 America/Catamarca AR 473 America/Cordoba AR 474 America/Jujuy AR 475 America/Mendoza AR 476 America/Rosario AR 477 Pacific/Pago_Pago AS 478 Europe/Vienna AT 479 Australia/Adelaide AU 480 Australia/Brisbane AU 481 Australia/Broken_Hill AU 482 Australia/Darwin AU 483 Australia/Hobart AU 484 Australia/Lindeman AU 485 Australia/Lord_Howe AU 486 Australia/Melbourne AU 487 Australia/Perth AU 488 Australia/Sydney AU 489 America/Aruba AW 490 Asia/Baku AZ 491 Europe/Sarajevo BA 492 America/Barbados BB 493 Asia/Dacca BD 494 Europe/Brussels BE 495 Africa/Ouagadougou BF 496 Europe/Sofia BG 497 Asia/Bahrain BH 498 Africa/Bujumbura BI 499 Africa/Porto-Novo BJ 500 Atlantic/Bermuda BM 501 Asia/Brunei BN 502 America/La_Paz BO 503 America/Cuiaba BR 504 America/Fortaleza BR 505 America/Maceio BR 506 America/Manaus BR 507 America/Noronha BR 508 America/Porto_Acre BR 509 America/Sao_Paulo BR 510 America/Nassau BS 511 Asia/Thimbu BT 512 Africa/Gaborone BW 513 Europe/Minsk BY 514 America/Belize BZ 515 America/Dawson CA 516 America/Dawson_Creek CA 517 America/Edmonton CA 518 America/Glace_Bay CA 519 America/Goose_Bay CA 520 America/Halifax CA 521 America/Inuvik CA 522 America/Iqaluit CA 523 America/Montreal CA 524 America/Nipigon CA 525 America/Pangnirtung CA 526 America/Rainy_River CA 527 America/Rankin_Inlet CA 528 America/Regina CA 529 America/St_Johns CA 530 America/Swift_Current CA 531 America/Thunder_Bay CA 532 America/Vancouver CA 533 America/Whitehorse CA 534 America/Winnipeg CA 535 America/Yellowknife CA 536 Indian/Cocos CC 537 Africa/Bangui CF 538 Africa/Brazzaville CG 539 Europe/Zurich CH 540 Africa/Abidjan CI 541 Pacific/Rarotonga CK 542 America/Santiago CL 543 Pacific/Easter CL 544 Africa/Douala CM 545 Asia/Chungking CN 546 Asia/Harbin CN 547 Asia/Kashgar CN 548 Asia/Shanghai CN 549 Asia/Urumqi CN 550 America/Bogota CO 551 America/Costa_Rica CR 552 America/Havana CU 553 Atlantic/Cape_Verde CV 554 Indian/Christmas CX 555 Asia/Nicosia CY 556 Europe/Prague CZ 557 Europe/Berlin DE 558 Africa/Djibouti DJ 559 Europe/Copenhagen DK 560 America/Dominica DM 561 America/Santo_Domingo DO 562 Africa/Algiers DZ 563 America/Guayaquil EC 564 Pacific/Galapagos EC 565 Europe/Tallinn EE 566 Africa/Cairo EG 567 Africa/El_Aaiun EH 568 Africa/Asmera ER 569 Africa/Ceuta ES 570 Atlantic/Canary ES 571 Europe/Madrid ES 572 Africa/Addis_Ababa ET 573 Europe/Helsinki FI 574 Pacific/Fiji FJ 575 Atlantic/Stanley FK 576 Pacific/Kosrae FM 577 Pacific/Ponape FM 578 Pacific/Truk FM 579 Pacific/Yap FM 580 Atlantic/Faeroe FO 581 Europe/Paris FR 582 Africa/Libreville GA 583 Europe/Belfast GB 584 Europe/London GB 585 America/Grenada GD 586 Asia/Tbilisi GE 587 America/Cayenne GF 588 Africa/Accra GH 589 Europe/Gibraltar GI 590 America/Godthab GL 591 America/Scoresbysund GL 592 America/Thule GL 593 Africa/Banjul GM 594 Africa/Conakry GN 595 America/Guadeloupe GP 596 Africa/Malabo GQ 597 Europe/Athens GR 598 Atlantic/South_Georgia GS 599 America/Guatemala GT 600 Pacific/Guam GU 601 Africa/Bissau GW 602 America/Guyana GY 603 Asia/Hong_Kong HK 604 America/Tegucigalpa HN 605 Europe/Zagreb HR 606 America/Port-au-Prince HT 607 Europe/Budapest HU 608 Asia/Jakarta ID 609 Asia/Jayapura ID 610 Asia/Ujung_Pandang ID 611 Europe/Dublin IE 612 Asia/Gaza IL 613 Asia/Jerusalem IL 614 Asia/Calcutta IN 615 Indian/Chagos IO 616 Asia/Baghdad IQ 617 Asia/Tehran IR 618 Atlantic/Reykjavik IS 619 Europe/Rome IT 620 America/Jamaica JM 621 Asia/Amman JO 622 Asia/Ishigaki JP 623 Asia/Tokyo JP 624 Africa/Nairobi KE 625 Asia/Bishkek KG 626 Asia/Phnom_Penh KH 627 Pacific/Enderbury KI 628 Pacific/Kiritimati KI 629 Pacific/Tarawa KI 630 Indian/Comoro KM 631 America/St_Kitts KN 632 Asia/Pyongyang KP 633 Asia/Seoul KR 634 Asia/Kuwait KW 635 America/Cayman KY 636 Asia/Alma-Ata KZ 637 Asia/Aqtau KZ 638 Asia/Aqtobe KZ 639 Asia/Vientiane LA 640 Asia/Beirut LB 641 America/St_Lucia LC 642 Europe/Vaduz LI 643 Asia/Colombo LK 644 Africa/Monrovia LR 645 Africa/Maseru LS 646 Europe/Vilnius LT 647 Europe/Luxembourg LU 648 Europe/Riga LV 649 Africa/Tripoli LY 650 Africa/Casablanca MA 651 Europe/Monaco MC 652 Europe/Chisinau MD 653 Indian/Antananarivo MG 654 Pacific/Kwajalein MH 655 Pacific/Majuro MH 656 Europe/Skopje MK 657 Africa/Bamako ML 658 Africa/Timbuktu ML 659 Asia/Rangoon MM 660 Asia/Ulan_Bator MN 661 Asia/Macao MO 662 Pacific/Saipan MP 663 America/Martinique MQ 664 Africa/Nouakchott MR 665 America/Montserrat MS 666 Europe/Malta MT 667 Indian/Mauritius MU 668 Indian/Maldives MV 669 Africa/Blantyre MW 670 America/Ensenada MX 671 America/Mazatlan MX 672 America/Mexico_City MX 673 America/Tijuana MX 674 Asia/Kuala_Lumpur MY 675 Asia/Kuching MY 676 Africa/Maputo MZ 677 Africa/Windhoek NA 678 Pacific/Noumea NC 679 Africa/Niamey NE 680 Pacific/Norfolk NF 681 Africa/Lagos NG 682 America/Managua NI 683 Europe/Amsterdam NL 684 Europe/Oslo NO 685 Asia/Katmandu NP 686 Pacific/Nauru NR 687 Pacific/Niue NU 688 Pacific/Auckland NZ 689 Pacific/Chatham NZ 690 Asia/Muscat OM 691 America/Panama PA 692 America/Lima PE 693 Pacific/Gambier PF 694 Pacific/Marquesas PF 695 Pacific/Tahiti PF 696 Pacific/Port_Moresby PG 697 Asia/Manila PH 698 Asia/Karachi PK 699 Europe/Warsaw PL 700 America/Miquelon PM 701 Pacific/Pitcairn PN 702 America/Puerto_Rico PR 703 Atlantic/Azores PT 704 Atlantic/Madeira PT 705 Europe/Lisbon PT 706 Pacific/Palau PW 707 America/Asuncion PY 708 Asia/Qatar QA 709 Indian/Reunion RE 710 Europe/Bucharest RO 711 Asia/Anadyr RU 712 Asia/Irkutsk RU 713 Asia/Kamchatka RU 714 Asia/Krasnoyarsk RU 715 Asia/Magadan RU 716 Asia/Novosibirsk RU 717 Asia/Omsk RU 718 Asia/Vladivostok RU 719 Asia/Yakutsk RU 720 Asia/Yekaterinburg RU 721 Europe/Kaliningrad RU 722 Europe/Moscow RU 723 Europe/Samara RU 724 Africa/Kigali RW 725 Asia/Riyadh SA 726 Pacific/Guadalcanal SB 727 Indian/Mahe SC 728 Africa/Khartoum SD 729 Europe/Stockholm SE 730 Asia/Singapore SG 731 Atlantic/St_Helena SH 732 Europe/Ljubljana SI 733 Arctic/Longyearbyen SJ 734 Atlantic/Jan_Mayen SJ 735 Europe/Bratislava SK 736 Africa/Freetown SL 737 Europe/San_Marino SM 738 Africa/Dakar SN 739 Africa/Mogadishu SO 740 America/Paramaribo SR 741 Africa/Sao_Tome ST 742 America/El_Salvador SV 743 Asia/Damascus SY 744 Africa/Mbabane SZ 745 America/Grand_Turk TC 746 Africa/Ndjamena TD 747 Indian/Kerguelen TF 748 Africa/Lome TG 749 Asia/Bangkok TH 750 Asia/Dushanbe TJ 751 Pacific/Fakaofo TK 752 Asia/Ashkhabad TM 753 Africa/Tunis TN 754 Pacific/Tongatapu TO 755 Europe/Istanbul TR 756 America/Port_of_Spain TT 757 Pacific/Funafuti TV 758 Asia/Taipei TW 759 Africa/Dar_es_Salaam TZ 760 Europe/Kiev UA 761 Europe/Simferopol UA 762 Africa/Kampala UG 763 Pacific/Johnston UM 764 Pacific/Midway UM 765 Pacific/Wake UM 766 America/Adak US 767 America/Anchorage US 768 America/Boise US 769 America/Chicago US 770 America/Denver US 771 America/Detroit US 772 America/Indianapolis US 773 America/Juneau US 774 America/Los_Angeles US 775 America/Louisville US 776 America/Menominee US 777 America/New_York US 778 America/Nome US 779 America/Phoenix US 780 America/Shiprock US 781 America/Yakutat US 782 Pacific/Honolulu US 783 America/Montevideo UY 784 Asia/Tashkent UZ 785 Europe/Vatican VA 786 America/St_Vincent VC 787 America/Caracas VE 788 America/Tortola VG 789 America/St_Thomas VI 790 Asia/Saigon VN 791 Pacific/Efate VU 792 Pacific/Wallis WF 793 Pacific/Apia WS 794 Asia/Aden YE 795 Indian/Mayotte YT 796 Europe/Belgrade YU 797 Africa/Johannesburg ZA 798 Africa/Lusaka ZM 799 Africa/Kinshasa ZR 800 Africa/Lubumbashi ZR 801 Africa/Harare ZW 803 6.7. Local Date/Time Format 805 The following format MAY be used to refer to future dates in a 806 local timezone. This is defined based on the format in section 807 5.6. 809 zone-char = ALPHA / DIGIT / "-" / "_" / "/" 810 zone-name = 1*zone_char 811 ; case insensitive interpretation 812 offset-hint = time-numoffset 814 local-datetime = full-date "T" partial-time " " zone-name 815 [" " offset-hint] 817 A local-datetime represents an event relative to a specific local 818 timezone. The offset-hint represents the generator's prediction of 819 what the UTC offset will be at that local time, and may become 820 incorrect if the rules for the specified zone are changed. The 821 offset-hint MAY be omitted if the generating program only knows 822 local time, but the zone-name is REQUIRED. This format SHOULD NOT 823 be used for timestamps or past events. 825 6.8. Examples 827 Here are some examples of Local Date/Time Format: 829 1999-12-31T23:59:59 America/New_York -05:00 831 This represents a time one (or two if there's a leap second) second 832 before the year 2000 in the timezone used in New York City in North 833 America (currently U.S. Eastern Time). The offset-hint is the 834 number to add to the local time to get an estimate UTC for that 835 date, so this will probably be equivalent to 2000-01-01T04:59:59Z. 837 2000-12-31T23:59:59 Australia/Adelaide +09:30 839 This represents a time one (or two if there's a leap second) second 840 before the 21st century in Adelaide, Australia. The hint suggests 841 that this will be equivalent to 2000-12-31T14:29:59Z. 843 2000-03-31T02:00:00 America/Los_Angeles -08:00 845 The represents a time of the 2nd hour on the 31st of March in Los 846 Angeles, USA. The hint suggests that would be equivalent to 2000- 847 03-31T10:00:00Z. However, if the U.S. government were to adopt the 848 daylight savings rules currently used by the European Union, which 849 change daylight savings on the last Sunday of March, then the time 850 would be equivalent to 2000-03-31T09:00:00Z. 852 7. Acknowledgements 854 May thanks to the following people who have provided helpful advice 855 for this document: Ned Freed, Neal McBurnett, David Keegel, Markus 856 Kuhn, Paul Eggert and Robert Elz. Thanks are also due to 857 participants of the IETF Calendaring/Scheduling working group 858 mailing list, and participants of the timezone mailing list. 860 8. References 862 [Zeller] Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol. 9, 863 Nov 1886. 865 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 866 Messages", RFC 822, University of Delaware, August 1982. 868 870 [ISO8601] "Data elements and interchange formats -- Information 871 interchange -- Representation of dates and times", ISO 8601:1988(E), 872 International Organization for Standardization, June, 1988. 874 [HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application 875 and Support", RFC 1123, Internet Engineering Task Force, October 1989. 877 879 [NTP] Mills, D., "Network Time Protocol (Version 3) Specification, 880 Implementation and Analysis", RFC 1305, University of Delaware, March 881 1992. 883 884 886 [ITU-R-TF] International Telecommunication Union Recommendations for 887 Time Signals and Frequency Standards Emissions. 889 891 9. Security Considerations 893 Since the local time zone of a site may be useful for determining a 894 time when systems are less likely to be monitored and might be more 895 susceptible to a security probe, some sites may wish to emit times 896 in UTC only. Others might consider this to be loss of useful 897 functionality at the hands of paranoia. 899 10. Author's Address 901 Chris Newman 902 Innosoft International, Inc. 903 1050 East Garvey Ave. South 904 West Covina, CA 91790 USA 906 Email: chris.newman@innosoft.com 908 APPENDIX 910 A. ISO 8601 Collected ABNF 912 ISO 8601 does not specify a formal grammar for the date and time 913 formats it defines. The following is an attempt to create a formal 914 grammar from ISO 8601. This is informational only and may contain 915 errors. ISO 8601 remains the authoratative reference. 917 Note that due to ambiguities in ISO 8601, some interpretations had 918 to be made. First, ISO 8601 is not clear if mixtures of basic and 919 extended format are permissible. This grammar permits mixtures. 920 ISO 8601 is not clear on whether an hour of 24 is permissible only 921 if minutes and seconds are 0. This assumes that an hour of 24 is 922 permissible in any context. Restrictions on date-mday in section 923 5.7 apply. ISO 8601 states that the "T" may be omitted under some 924 circumstances. This grammar requires the "T" to avoid ambiguity. 926 ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction 927 be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 928 gives examples where the decimal fractions are not preceeded by a 929 "0". This grammar assumes section 5.3.1.3 is correct and that 930 Annex B.2 is in error. 932 date-century = 2DIGIT ; 00-99 933 date-decade = DIGIT ; 0-9 934 date-subdecade = DIGIT ; 0-9 935 date-year = date-decade date-subdecade 936 date-fullyear = date-century date-year 937 date-month = 2DIGIT ; 01-12 938 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday 939 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 940 date-yday = 3DIGIT ; 001-365, 001-366 based on year 941 date-week = 2DIGIT ; 01-52, 01-53 based on year 943 datepart-fullyear = [date-century] date-year ["-"] 944 datepart-ptyear = "-" [date-subdecade ["-"]] 945 datepart-wkyear = datepart-ptyear / datepart-fullyear 947 dateopt-century = "-" / date-century 948 dateopt-fullyear = "-" / datepart-fullyear 949 dateopt-year = "-" / (date-year ["-"]) 950 dateopt-month = "-" / (date-month ["-"]) 951 dateopt-week = "-" / (date-week ["-"]) 953 datespec-full = datepart-fullyear date-month ["-"] date-mday 954 datespec-year = date-century / dateopt-century date-year 955 datespec-month = "-" dateopt-year date-month [["-"] date-mday] 956 datespec-mday = "--" dateopt-month date-mday 957 datespec-week = datepart-wkyear "W" 958 (date-week / dateopt-week date-wday) 959 datespec-wday = "---" date-wday 960 datespec-yday = dateopt-fullyear date-yday 962 date = datespec-full / datespec-year / datespec-month / 963 datespec-mday / datespec-week / datespec-wday / datespec-yday 965 Time: 967 time-hour = 2DIGIT ; 00-24 968 time-minute = 2DIGIT ; 00-59 969 time-second = 2DIGIT ; 00-59, 00-60 based on leap-second rules 970 time-fraction = ("," / ".") 1*DIGIT 971 time-numoffset = ("+" / "-") time-hour [[":"] time-minute] 972 time-zone = "Z" / time-numoffset 973 timeopt-hour = "-" / (time-hour [":"]) 974 timeopt-minute = "-" / (time-minute [":"]) 976 timespec-hour = time-hour [[":"] time-minute [[":"] time-second]] 977 timespec-minute = timeopt-hour time-minute [[":"] time-second] 978 timespec-second = "-" timeopt-minute time-second 979 timespec-base = timespec-hour / timespec-minute / timespec-second 981 time = timespec-base [time-fraction] [time-zone] 983 iso-date-time = date "T" time 985 Durations (periods): 987 dur-second = 1*DIGIT "S" 988 dur-minute = 1*DIGIT "M" [dur-second] 989 dur-hour = 1*DIGIT "H" [dur-minute] 990 dur-time = "T" (dur-hour / dur-minute / dur-second) 991 dur-day = 1*DIGIT "D" 992 dur-week = 1*DIGIT "W" 993 dur-month = 1*DIGIT "M" [dur-day] 994 dur-year = 1*DIGIT "Y" [dur-month] 995 dur-date = (dur-day / dur-month / dur-year) [dur-time] 997 duration = "P" (dur-date / dur-time / dur-week) 999 Periods: 1001 period-explicit = date-time "/" date-time 1002 period-start = date-time "/" duration 1003 period-end = duration "/" date-time 1005 period = period-explicit / period-start / period-end 1007 B. Day of the Week 1009 The following is a sample C subroutine loosly based on Zeller's 1010 Congruence [Zeller] which may be used to obtain the day of the 1011 week: 1013 char *day_of_week(int day, int month, int year) 1014 { 1015 char *dayofweek[] = { 1016 "Sunday", "Monday", "Tuesday", "Wednesday", 1017 "Thursday", "Friday", "Saturday" 1018 }; 1020 /* adjust months so February is the last one */ 1021 month -= 2; 1022 if (month < 1) { 1023 month += 12; 1024 --year; 1025 } 1026 /* split by century */ 1027 cent = year / 100; 1028 year %= 100; 1029 return (dayofweek[((26 * month - 2) / 10 + day + year 1030 + year / 4 + cent / 4 - 2 * cent) % 7]); 1031 } 1033 C. Leap Years 1035 Here's a sample C subroutine to calculate if a year is a leap year: 1037 /* This returns non-zero if year is a leap year. Must use 4 digit year. 1038 */ 1039 int leap_year(int year) 1040 { 1041 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 1042 }