idnits 2.17.1 draft-ryzokuken-datetime-extended-01.txt: -(686): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(705): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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.) ** There are 4 instances of too long lines in the document, the longest one being 24 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC3339, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 January 2021) is 1187 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) == Missing Reference: 'ISO8601' is mentioned on line 716, but not defined == Missing Reference: 'RFC3339' is mentioned on line 720, but not defined == Missing Reference: 'RFC5226' is mentioned on line 355, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring Extensions Working Group U. Sharma 3 Internet-Draft Igalia, S.L. 4 Obsoletes: 3339 (if approved) 22 January 2021 5 Intended status: Standards Track 6 Expires: 26 July 2021 8 Date and Time on the Internet: Timestamps with additional information 9 draft-ryzokuken-datetime-extended-01 11 Abstract 13 This document defines a date and time format for use in Internet 14 protocols for representation of dates and times using the proleptic 15 Gregorian calendar, with optional extensions representing additional 16 information including a time zone. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 26 July 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Two Digit Years . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Local Time . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Coordinated Universal Time (UTC) . . . . . . . . . . . . 4 56 4.2. Local Offsets . . . . . . . . . . . . . . . . . . . . . . 4 57 4.3. Unknown Local Offset Convention . . . . . . . . . . . . . 5 58 4.4. Unqualified Local Time . . . . . . . . . . . . . . . . . 5 59 5. Date and Time format . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Ordering . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Human Readability . . . . . . . . . . . . . . . . . . . . 6 62 5.3. Rarely Used Options . . . . . . . . . . . . . . . . . . . 7 63 5.4. Redundant Information . . . . . . . . . . . . . . . . . . 7 64 5.5. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.6. Informative . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.7. Namespaced . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.8. Internet Date/Time Format . . . . . . . . . . . . . . . . 11 68 5.9. Restrictions . . . . . . . . . . . . . . . . . . . . . . 12 69 5.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 7. Normative references . . . . . . . . . . . . . . . . . . . . 15 72 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Appendix A. Day of the Week . . . . . . . . . . . . . . . . . . 16 74 Appendix B. Leap Years . . . . . . . . . . . . . . . . . . . . . 17 75 Appendix C. Leap Seconds . . . . . . . . . . . . . . . . . . . . 17 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Date and time formats cause a lot of confusion and interoperability 81 problems on the Internet. This document addresses many of the 82 problems encountered and makes recommendations to improve consistency 83 and interoperability when representing and using date and time in 84 Internet protocols. 86 This document includes an extension to an Internet profile of the 87 [ISO8601] standard for representation of dates and times using the 88 proleptic Gregorian calendar alongside any additional information. 90 There are many ways in which date and time values might appear in 91 Internet protocols: this document focuses on just one common usage, 92 viz. timestamps for Internet protocol events. This limited 93 consideration has the following consequences: 95 * All dates and times are assumed to be in the "current era", 96 somewhere between 0000AD and 9999AD. 98 * All times expressed have a stated relationship (offset) to 99 Coordinated Universal Time (UTC). Certain applications require 100 the presence of a time zone in order to perform scheduling as well 101 as handle Daylight Savings Time transitions properly. In that 102 case, an optional time zone ID may be included. 104 * Timestamps can express times that occurred before the introduction 105 of UTC. Such timestamps are expressed relative to universal time, 106 using the best available practice at the stated time. 108 * Date and time expressions indicate an instant in time. 109 Description of time periods, or intervals, is not covered here. 111 2. Definitions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 UTC Coordinated Universal Time as maintained by the Bureau 118 International des Poids et Mesures (BIPM). 120 second A basic unit of measurement of time in the International 121 System of Units. It is defined as the duration of 9,192,631,770 122 cycles of microwave light absorbed or emitted by the hyperfine 123 transition of cesium-133 atoms in their ground state undisturbed 124 by external fields. 126 minute A period of time of 60 seconds. However, see also the 127 restrictions in section Section 5.9 and Appendix C for how leap 128 seconds are denoted within minutes. 130 hour A period of time of 60 minutes. 132 day A period of time of 24 hours. 134 leap year In the proleptic Gregorian calendar, a year which has 366 135 days. A leap year is a year whose number is divisible by four an 136 integral number of times, except that if it is a centennial year 137 (i.e. divisible by one hundred) it shall also be divisible by four 138 hundred an integral number of times. 140 ABNF Augmented Backus-Naur Form, a format used to represent 141 permissible strings in a protocol or language, as defined in 142 [RFC2234]. 144 Email Date/Time Format The date/time format used by Internet Mail as 145 defined by [RFC2822]. 147 Internet Date/Time Format The date/time format defined in section 5 148 of this document. 150 Timestamp This term is used in this document to refer to an 151 unambiguous representation of some instant in time. 153 Z A suffix which, when applied to a time, denotes a UTC offset of 154 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 155 representation of the letter "Z". 157 Time Zone A time zone that is a included in the Time Zone Database 158 (often called "tz" or "zoneinfo") maintained by IANA. 160 For more information about time scales, see Appendix E of [RFC1305], 161 Section 3 of [ISO8601], and the appropriate ITU documents (ITU-R-TF). 163 3. Two Digit Years 165 The use of 2 (and 3) digit years was allowed but deprecated in 166 [RFC3339], the predecessor of this document. 168 The use of such a format is no longer allowed, and implementations 169 should use either a standard 4-digit year or the extended 6-digit 170 value with a sign. 172 4. Local Time 174 4.1. Coordinated Universal Time (UTC) 176 Because the daylight saving rules for local time zones are so 177 convoluted and can change based on local law at unpredictable times, 178 true interoperability is best achieved by using Coordinated Universal 179 Time (UTC). This specification by itself does not cater to local 180 time zone rules. However, certain implementations may be expected 181 to. For these situations, a timestamp may additionally include a 182 local time zone that the implementations can take into account. 184 4.2. Local Offsets 186 The offset between local time and UTC is often useful information. 187 For example, in electronic mail (RFC2822, [RFC2822]) the local offset 188 provides a useful heuristic to determine the probability of a prompt 189 response. Attempts to label local offsets with alphabetic strings 190 have resulted in poor interoperability in the past [RFC1123]. As a 191 result, RFC2822 [RFC2822] has made numeric offsets mandatory. 193 Numeric offsets are calculated as "local time minus UTC". So the 194 equivalent time in UTC can be determined by subtracting the offset 195 from the local time. For example, "18:50:00-04:00" is the same time 196 as "22:50:00Z". (This example shows negative offsets handled by 197 adding the absolute value of the offset.) 199 Numeric offsets may differ from UTC by any number of seconds, or even 200 a fraction of seconds. This can be easily represented by including 201 an optional seconds value in the offset, which may further optionally 202 include a fraction of seconds behind a decimal point, for example 203 "+12:34:56.789". This is especially useful in the case of certain 204 historical time zones. 206 4.3. Unknown Local Offset Convention 208 If the time in UTC is known, but the offset to local time is unknown, 209 this can be represented with an offset of "-00:00". This differs 210 semantically from an offset of "Z" or "+00:00", which imply that UTC 211 is the preferred reference point for the specified time. RFC2822 212 [RFC2822] describes a similar convention for email. 214 4.4. Unqualified Local Time 216 A number of devices currently connected to the Internet run their 217 internal clocks in local time and are unaware of UTC. While the 218 Internet does have a tradition of accepting reality when creating 219 specifications, this should not be done at the expense of 220 interoperability. Since interpretation of an unqualified local time 221 zone will fail in approximately 23/24 of the globe, the 222 interoperability problems of unqualified local time are deemed 223 unacceptable for the Internet. Systems that are configured with a 224 local time, are unaware of the corresponding UTC offset, and depend 225 on time synchronization with other Internet systems, MUST use a 226 mechanism that ensures correct synchronization with UTC. Some 227 suitable mechanisms are: 229 * Use Network Time Protocol [RFC1305] to obtain the time in UTC. 231 * Use another host in the same local time zone as a gateway to the 232 Internet. This host MUST correct unqualified local times that are 233 transmitted to other hosts. 235 * Prompt the user for the local time zone and daylight saving rule 236 settings. 238 5. Date and Time format 240 This section discusses desirable qualities of date and time formats 241 and defines a format that extends the profile of ISO 8601 for use in 242 Internet protocols. 244 5.1. Ordering 246 If date and time components are ordered from least precise to most 247 precise, then a useful property is achieved. Assuming that the time 248 zones of the dates and times are the same (e.g., all in UTC), 249 expressed using the same string (e.g., all "Z" or all "+00:00"), all 250 times have the same number of fractional second digits, and they all 251 have the same suffix (or none), then the date and time strings may be 252 sorted as strings (e.g., using the "strcmp()" function in C) and a 253 time-ordered sequence will result. The presence of optional 254 punctuation would violate this characteristic. 256 5.2. Human Readability 258 Human readability has proved to be a valuable feature of Internet 259 protocols. Human readable protocols greatly reduce the costs of 260 debugging since telnet often suffices as a test client and network 261 analyzers need not be modified with knowledge of the protocol. On 262 the other hand, human readability sometimes results in 263 interoperability problems. For example, the date format "10/11/1996" 264 is completely unsuitable for global interchange because it is 265 interpreted differently in different countries. In addition, the 266 date format in (RFC822) has resulted in interoperability problems 267 when people assumed any text string was permitted and translated the 268 three letter abbreviations to other languages or substituted date 269 formats which were easier to generate (e.g. the format used by the C 270 function "ctime"). For this reason, a balance must be struck between 271 human readability and interoperability. 273 Because no date and time format is readable according to the 274 conventions of all countries, Internet clients SHOULD be prepared to 275 transform dates into a display format suitable for the locality. 276 This may include translating UTC to local time as well as converting 277 from the Gregorian calendar to the viewer's preferred calendar. 279 5.3. Rarely Used Options 281 A format which includes rarely used options is likely to cause 282 interoperability problems. This is because rarely used options are 283 less likely to be used in alpha or beta testing, so bugs in parsing 284 are less likely to be discovered. Rarely used options should be made 285 mandatory or omitted for the sake of interoperability whenever 286 possible. 288 5.4. Redundant Information 290 If a date/time format includes redundant information, that introduces 291 the possibility that the redundant information will not correlate. 292 For example, including the day of the week in a date/time format 293 introduces the possibility that the day of week is incorrect but the 294 date is correct, or vice versa. Since it is not difficult to compute 295 the day of week from a date (see Appendix A), the day of week should 296 not be included in a date/time format. 298 5.5. Simplicity 300 The complete set of date and time formats specified in ISO 8601 301 [ISO8601] is quite complex in an attempt to provide multiple 302 representations and partial representations. Internet protocols have 303 somewhat different requirements and simplicity has proved to be an 304 important characteristic. In addition, Internet protocols usually 305 need complete specification of data in order to achieve true 306 interoperability. Therefore, the complete grammar for ISO 8601 is 307 deemed too complex for most Internet protocols. 309 The following section defines a format that in an extension of a 310 profile of ISO 8601 for use on the Internet. It is a conformant 311 subset of the ISO 8601 extended format with additional information 312 optionally suffixed. Simplicity is achieved by making most fields 313 and punctuation mandatory. 315 5.6. Informative 317 The format should allow implementations to specify additional 318 important information in addition to the bare timestamp. This is 319 done by allowing implementations to include an informative suffix at 320 the end with as many tags as required, each with a hyphen separated 321 key and value. The value can be a hyphen delimited list of multiple 322 values. 324 In case a key is repeated or conflicted, the implementations should 325 give precedence to whichever value is positioned first. 327 5.7. Namespaced 329 Since the suffix can include all sorts of additional information, 330 different standards bodies/organizations need a way to identify which 331 part adheres to their standards. For this, all information needs to 332 be namespaced. Each key is therefore divided into two hyphen- 333 separated sections: the namespace and the key. For example, the 334 calendar as defined by the Unicode consortium could be included as 335 "u-ca-". 337 All single-character namespaces are reserved for BCP47 extensions 338 recorded in the BCP47 extensions registry. For these namespaces: 340 * Case differences are ignored. 342 * The namespace is restricted to single alphanum, corresponding to 343 extension singletons ('x' can be used for a private use 344 extension). 346 * In addition, for CLDR extensions: 348 - There must be a "namespace-key" and it is restricted to 2 349 "alphanum" characters. 351 - A "suffix-value" is limited to "3*8alphanum". 353 Multi-character namespaces can be registered specifically for use in 354 this format. They are assigned by IANA using the "IETF Review" 355 policy defined by [RFC5226]. This policy requires the development of 356 an RFC, which SHALL define the name, purpose, processes, and 357 procedures for maintaining the subtags. The maintaining or 358 registering authority, including name, contact email, discussion list 359 email, and URL location of the registry, MUST be indicated clearly in 360 the RFC. The RFC MUST specify or include each of the following: 362 * The specification MUST reference the specific version or revision 363 of this document that governs its creation and MUST reference this 364 section of this document. 366 * The specification and all keys defined by the specification MUST 367 follow the ABNF and other rules for the formation of keys as 368 defined in this document. In particular, it MUST specify that 369 case is not significant and that keys MUST NOT exceed eight 370 characters in length. 372 * The specification MUST specify a canonical representation. 374 * The specification of valid keys MUST be available over the 375 Internet and at no cost. 377 * The specification MUST be in the public domain or available via a 378 royalty-free license acceptable to the IETF and specified in the 379 RFC. 381 * The specification MUST be versioned, and each version of the 382 specification MUST be numbered, dated, and stable. 384 * The specification MUST be stable. That is, namespace keys, once 385 defined by a specification, MUST NOT be retracted or change in 386 meaning in any substantial way. 388 * The specification MUST include, in a separate section, the 389 registration form reproduced in this section (below) to be used in 390 registering the namespace upon publication as an RFC. 392 * IANA MUST be informed of changes to the contact information and 393 URL for the specification. 395 IANA will maintain a registry of allocated multi-character 396 namespaces. This registry MUST use the record-jar format described 397 by the ABNF in [RFC5646]. Upon publication of a namespace as an RFC, 398 the maintaining authority defined in the RFC MUST forward this 399 registration form to , who MUST forward the 400 request to . The maintaining authority of the 401 namespace MUST maintain the accuracy of the record by sending an 402 updated full copy of the record to with the 403 subject line "TIMESTAMP FORMAT NAMESPACE UPDATE" whenever content 404 changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 405 'URL' fields MAY be modified in these updates. 407 Failure to maintain this record, maintain the corresponding registry, 408 or meet other conditions imposed by this section of this document MAY 409 be appealed to the IESG [RFC2028] under the same rules as other IETF 410 decisions (see [RFC2026]) and MAY result in the authority to maintain 411 the extension being withdrawn or reassigned by the IESG. 413 %% 414 Identifier: 415 Description: 416 Comments: 417 Added: 418 RFC: 419 Authority: 420 Contact_Email: 421 Mailing_List: 422 URL: 423 %% 425 Figure 1: Format of Records in the Timestamp Format Namespace 426 Registry 428 'Identifier' contains the multi-character sequence assigned to the 429 namespace. The Internet-Draft submitted to define the namespace 430 SHOULD specify which sequence to use, although the IESG MAY change 431 the assignment when approving the RFC. 433 'Description' contains the name and description of the namespace. 435 'Comments' is an OPTIONAL field and MAY contain a broader description 436 of the namespace. 438 'Added' contains the date the namespace's RFC was published in the 439 "date-full" format specified in Figure 2. For example: 2004-06-28 440 represents June 28, 2004, in the Gregorian calendar. 442 'RFC' contains the RFC number assigned to the namespace. 444 'Authority' contains the name of the maintaining authority for the 445 namespace. 447 'Contact_Email' contains the email address used to contact the 448 maintaining authority. 450 'Mailing_List' contains the URL or subscription email address of the 451 mailing list used by the maintaining authority. 453 'URL' contains the URL of the registry for this namespace. 455 The determination of whether an Internet-Draft meets the above 456 conditions and the decision to grant or withhold such authority rests 457 solely with the IESG and is subject to the normal review and appeals 458 process associated with the RFC process. 460 5.8. Internet Date/Time Format 462 The following extension of a profile of [ISO8601] dates SHOULD be 463 used in new protocols on the Internet. This is specified using the 464 syntax description notation defined in [RFC2234]. 466 alphanum = ALPHA / DIGIT 468 date-year = 4DIGIT / ("+" / "-") 6DIGIT 469 date-month = 2DIGIT ; 01-12 470 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 471 date-full = date-year "-" date-month "-" date-mday 473 time-hour = 2DIGIT ; 00-23 474 time-minute = 2DIGIT ; 00-59 475 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules 476 time-secfrac = "." 1*DIGIT 477 time-partial = time-hour ":" time-minute ":" time-second [time-secfrac] 478 time-numoffset = ("+" / "-") time-partial 479 time-offset = "Z" / time-numoffset 480 time-full = time-partial time-offset 482 time-zone-char = ALPHA / "." / "_" 483 time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".." 484 time-zone-id = time-zone-part *("/" time-zone-part) 485 time-zone = "[" time-zone-id "]" 487 namespace = 1*alphanum 488 namespace-key = 1*alphanum 489 suffix-key = namespace ["-" namespace-key] 491 suffix-value = 1*alphanum 492 suffix-values = suffix-value *("-" suffix-value) 493 suffix-tag = "[" suffix-key "-" suffix-values "]" 494 suffix = [timezone] *suffix-tag 496 date-time = date-full "T" time-full suffix 498 Figure 2 500 | NOTE 1: Per [RFC2234] and ISO8601, the "T" and "Z" characters 501 | in this syntax may alternatively be lower case "t" or "z" 502 | respectively. 504 This date/time format may be used in some environments or contexts 505 that distinguish between the upper- and lower-case letters 'A'-'Z' 506 and 'a'-'z' (e.g. XML). Specifications that use this format in such 507 environments MAY further limit the date/time syntax so that the 508 letters 'T' and 'Z' used in the date/time syntax must always be upper 509 case. Applications that generate this format SHOULD use upper case 510 letters. 512 | NOTE 2: ISO 8601 defines date and time separated by "T". 513 | Applications using this syntax may choose, for the sake of 514 | readability, to specify a full-date and full-time separated by 515 | (say) a space character. 517 5.9. Restrictions 519 The grammar element date-mday represents the day number within the 520 current month. The maximum value varies based on the month and year 521 as follows: 523 +==============+=====================+============================+ 524 | Month Number | Month/Year | Maximum value of date-mday | 525 +==============+=====================+============================+ 526 | 01 | January | 31 | 527 +--------------+---------------------+----------------------------+ 528 | 02 | February, normal | 28 | 529 +--------------+---------------------+----------------------------+ 530 | 02 | February, leap year | 29 | 531 +--------------+---------------------+----------------------------+ 532 | 03 | March | 31 | 533 +--------------+---------------------+----------------------------+ 534 | 04 | April | 30 | 535 +--------------+---------------------+----------------------------+ 536 | 05 | May | 31 | 537 +--------------+---------------------+----------------------------+ 538 | 06 | June | 30 | 539 +--------------+---------------------+----------------------------+ 540 | 07 | July | 31 | 541 +--------------+---------------------+----------------------------+ 542 | 08 | August | 31 | 543 +--------------+---------------------+----------------------------+ 544 | 09 | September | 30 | 545 +--------------+---------------------+----------------------------+ 546 | 10 | October | 31 | 547 +--------------+---------------------+----------------------------+ 548 | 11 | November | 30 | 549 +--------------+---------------------+----------------------------+ 550 | 12 | December | 31 | 551 +--------------+---------------------+----------------------------+ 553 Table 1: Days in each month 555 Appendix B contains sample C code to determine if a year is a leap 556 year. 558 The grammar element time-second may have the value "60" at the end of 559 months in which a leap second occurs - to date: June (XXXX-06- 560 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix C for 561 a table of leap seconds. It is also possible for a leap second to be 562 subtracted, at which times the maximum value of time-second is "58". 563 At all other times the maximum value of time-second is "59". 564 Further, in time zones other than "Z", the leap second point is 565 shifted by the zone offset (so it happens at the same instant around 566 the globe). 568 Leap seconds cannot be predicted far into the future. The 569 International Earth Rotation Service publishes bulletins (IERS) that 570 announce leap seconds with a few weeks' warning. Applications should 571 not generate timestamps involving inserted leap seconds until after 572 the leap seconds are announced. 574 Although ISO 8601 permits the hour to be "24", this extension of a 575 profile of ISO 8601 only allows values between "00" and "23" for the 576 hour in order to reduce confusion. 578 5.10. Examples 580 Here are some examples of Internet date/time format. 582 1985-04-12T23:20:50.52Z 584 Figure 3 586 This represents 20 minutes and 50.52 seconds after the 23rd hour of 587 April 12th, 1985 in UTC. 589 +001985-04-12T23:20:50.52Z 591 Figure 4 593 This represents the same instant as the previous example but with the 594 expanded 6-digit year format. 596 1996-12-19T16:39:57-08:00 598 Figure 5 600 This represents 39 minutes and 57 seconds after the 16th hour of 601 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 602 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z 603 in UTC. 605 1996-12-19T16:39:57-08:00[America/Los_Angeles] 607 Figure 6 609 This represents the exact same instant as the previous example but 610 additionally specifies the human time zone associated with it for 611 time zone aware implementations to take into account. 613 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca-hebrew] 615 Figure 7 617 This represents the exact same instant but it informs calendar-aware 618 implementations that they should project it to the Hebrew calendar. 620 1990-12-31T23:59:60Z 622 Figure 8 624 This represents the leap second inserted at the end of 1990. 626 1990-12-31T15:59:60-08:00 628 Figure 9 630 This represents the same leap second in Pacific Standard Time, 8 631 hours behind UTC. 633 1937-01-01T12:00:27.87+00:19:32.130 635 Figure 10 637 This represents the same instant of time as noon, January 1, 1937, 638 Netherlands time. Standard time in the Netherlands was exactly 19 639 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 640 1937-06-30. 642 1937-01-01T12:00:27.87+00:19:32.130[u-ca-japanese] 644 Figure 11 646 This represents the exact same instant as the previous example but 647 additionally specifies the human calendar associated with it for 648 calendar aware implementations to take into account. 650 1937-01-01T12:00:27.87+00:19:32.130[u-ca-islamic-civil] 652 Figure 12 654 Since there's not a single agreed upon way to deal with dates in the 655 Islamic calendar, it provides another value to disambiguate between 656 the different interpretations. 658 1937-01-01T12:00:27.87+00:19:32.130[x-foo-bar][x-baz-bat] 660 Figure 13 662 This timestamp utilizes the private use namespace to declare two 663 additional pieces of information in the suffix that can be 664 interpreted by any compatible implementations and ignored otherwise. 666 6. Security Considerations 668 Since the local time zone of a site may be useful for determining a 669 time when systems are less likely to be monitored and might be more 670 susceptible to a security probe, some sites may wish to emit times in 671 UTC only. Others might consider this to be loss of useful 672 functionality at the hands of paranoia. 674 7. Normative references 676 [RFC2822] Resnick, P., Ed., "Internet Message Format", IETF RFC 677 2822, IETF RFC 2822, DOI 10.17487/RFC2822, April 2001, 678 . 680 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 681 Specifications: ABNF", IETF RFC 2234, IETF RFC 2234, 682 DOI 10.17487/RFC2234, November 1997, 683 . 685 [RFC1123] Braden, R., Ed., "Requirements for Internet 686 Hosts — Application and Support", IETF RFC 1123, IETF RFC 687 1123, DOI 10.17487/RFC1123, October 1989, 688 . 690 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 691 Specification, Implementation and Analysis", IETF RFC 692 1305, IETF RFC 1305, DOI 10.17487/RFC1305, March 1992, 693 . 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", IETF RFC 2119, IETF RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 701 Languages", IETF RFC 5646, IETF RFC 5646, 702 DOI 10.17487/RFC5646, September 2009, 703 . 705 [RFC2026] Bradner, S., "The Internet Standards Process — Revision 706 3", IETF RFC 2026, IETF RFC 2026, DOI 10.17487/RFC2026, 707 October 1996, . 709 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 710 the IETF Standards Process", IETF RFC 2028, IETF RFC 2028, 711 DOI 10.17487/RFC2028, October 1996, 712 . 714 8. Bibliography 716 [ISO8601] International Organization for Standardization, "Data 717 elements and interchange formats", ISO 8601:1988, June 718 1988, . 720 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 721 Timestamps", IETF RFC 3339, IETF RFC 3339, 722 DOI 10.17487/RFC3339, July 2002, 723 . 725 Appendix A. Day of the Week 727 The following is a sample C subroutine loosely based on Zeller's 728 Congruence (ZELLER) which may be used to obtain the day of the week 729 for dates on or after 0000-03-01: 731 char *day_of_week(int day, int month, int year) 732 { 733 int cent; 734 char *dayofweek[] = { 735 "Sunday", "Monday", "Tuesday", "Wednesday", 736 "Thursday", "Friday", "Saturday" 737 }; 739 /* adjust months so February is the last one */ 740 month -= 2; 741 if (month < 1) { 742 month += 12; 743 --year; 744 } 745 /* split by century */ 746 cent = year / 100; 747 year %= 100; 748 return (dayofweek[((26 * month - 2) / 10 + day + year 749 + year / 4 + cent / 4 + 5 * cent) % 7]); 750 } 752 Figure 14 754 Appendix B. Leap Years 756 Here is a sample C subroutine to calculate if a year is a leap year: 758 /* This returns non-zero if year is a leap year. Must use 4 digit 759 year. 760 */ 761 int leap_year(int year) 762 { 763 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 764 } 766 Figure 15 768 Appendix C. Leap Seconds 770 Information about leap seconds can be found at the US Navy 771 Oceanography Portal (https://www.usno.navy.mil/USNO/time/master- 772 clock/leap-seconds). In particular, it notes that: 774 | The decision to introduce a leap second in UTC is the 775 | responsibility of the International Earth Rotation Service (IERS). 776 | According to the CCIR Recommendation, first preference is given to 777 | the opportunities at the end of December and June, and second 778 | preference to those at the end of March and September. 780 When required, insertion of a leap second occurs as an extra second 781 at the end of a day in UTC, represented by a timestamp of the form 782 YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all 783 time zones, so that time zone relationships are not affected. See 784 section Section 5.10 for some examples of leap second times. 786 The following table is an excerpt from the table maintained by the 787 United States Naval Observatory. The source data is located at the 788 US Navy Oceanography Portal (ftp://maia.usno.navy.mil/ser7/tai- 789 utc.dat). 791 This table shows the date of the leap second, and the difference 792 between the time standard TAI (which isn't adjusted by leap seconds) 793 and UTC after that leap second. 795 +============+=============================+ 796 | UTC Date | TAI - UTC After Leap Second | 797 +============+=============================+ 798 | 1972-06-30 | 11 | 799 +------------+-----------------------------+ 800 | 1972-12-31 | 12 | 801 +------------+-----------------------------+ 802 | 1973-12-31 | 13 | 803 +------------+-----------------------------+ 804 | 1974-12-31 | 14 | 805 +------------+-----------------------------+ 806 | 1975-12-31 | 15 | 807 +------------+-----------------------------+ 808 | 1976-12-31 | 16 | 809 +------------+-----------------------------+ 810 | 1977-12-31 | 17 | 811 +------------+-----------------------------+ 812 | 1978-12-31 | 18 | 813 +------------+-----------------------------+ 814 | 1979-12-31 | 19 | 815 +------------+-----------------------------+ 816 | 1981-06-30 | 20 | 817 +------------+-----------------------------+ 818 | 1982-06-30 | 21 | 819 +------------+-----------------------------+ 820 | 1983-06-30 | 22 | 821 +------------+-----------------------------+ 822 | 1985-06-30 | 23 | 823 +------------+-----------------------------+ 824 | 1987-12-31 | 24 | 825 +------------+-----------------------------+ 826 | 1989-12-31 | 25 | 827 +------------+-----------------------------+ 828 | 1990-12-31 | 26 | 829 +------------+-----------------------------+ 830 | 1992-06-30 | 27 | 831 +------------+-----------------------------+ 832 | 1993-06-30 | 28 | 833 +------------+-----------------------------+ 834 | 1994-06-30 | 29 | 835 +------------+-----------------------------+ 836 | 1995-12-31 | 30 | 837 +------------+-----------------------------+ 838 | 1997-06-30 | 31 | 839 +------------+-----------------------------+ 840 | 1998-12-31 | 32 | 841 +------------+-----------------------------+ 843 Table 2: Historic leap seconds 845 Author's Address 847 Ujjwal Sharma 848 Igalia, S.L. 850 Email: ryzokuken@igalia.com