idnits 2.17.1 draft-ryzokuken-datetime-updated-00.txt: -(494): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(513): 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 3 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 3 instances of too long lines in the document, the longest one being 4 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 (21 February 2021) is 1153 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 524, but not defined == Missing Reference: 'IERS' is mentioned on line 606, but not defined == Missing Reference: 'CGPM' is mentioned on line 540, but not defined == Missing Reference: 'ITU-R-TF' is mentioned on line 596, but not defined == Missing Reference: 'RFC3339' is mentioned on line 528, but not defined == Missing Reference: 'ISO8601-2000' is mentioned on line 533, but not defined == Missing Reference: 'ZELLER' is mentioned on line 550, but not defined == Unused Reference: 'RFC5646' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 517, but no explicit reference was found in the text ** 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: 6 errors (**), 0 flaws (~~), 12 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) 21 February 2021 5 Intended status: Standards Track 6 Expires: 25 August 2021 8 Date and Time on the Internet: Timestamps 9 draft-ryzokuken-datetime-updated-00 11 Abstract 13 This document defines a date and time format for use in Internet 14 protocols that is a profile of the ISO 8601 standard for 15 representation of dates and times using the proleptic Gregorian 16 calendar. 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 25 August 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) . . . . . . . . . . . . 5 56 4.2. Local Offsets . . . . . . . . . . . . . . . . . . . . . . 5 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. Internet Date/Time Format . . . . . . . . . . . . . . . . 7 66 5.7. Restrictions . . . . . . . . . . . . . . . . . . . . . . 8 67 5.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. Normative references . . . . . . . . . . . . . . . . . . . . 11 70 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Day of the Week . . . . . . . . . . . . . . . . . . 12 72 Appendix B. Leap Years . . . . . . . . . . . . . . . . . . . . . 13 73 Appendix C. Leap Seconds . . . . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 Date and time formats cause a lot of confusion and interoperability 79 problems on the Internet. This document addresses many of the 80 problems encountered and makes recommendations to improve consistency 81 and interoperability when representing and using date and time in 82 Internet protocols. 84 This document includes an Internet profile of the [ISO8601] standard 85 for representation of dates and times using the proleptic 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 * All dates and times are assumed to be in the "current era", 94 somewhere between 0000AD and 9999AD. 96 * 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 * Timestamps can express times that occurred before the introduction 107 of UTC. Such timestamps are expressed relative to universal time, 108 using the best available practice at the stated time. 110 * Date and time expressions indicate an instant in time. 111 Description of time periods, or intervals, is not covered here. 113 2. Definitions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 UTC Coordinated Universal Time as maintained since 1988 by the 120 Bureau International des Poids et Mesures (BIPM) in conjunction 121 with leap seconds as announced by the International Earth Rotation 122 and Reference Frames Service [IERS]. From 1972 through 1987 UTC 123 was maintained entirely by Bureau International de l'Heure (BIH). 124 Before 1972 UTC was not generally recognized and civil time was 125 determined by individual jurisdictions using different techniques 126 for attempting to follow Universal Time based on measuring the 127 rotation of the earth. 129 second The unit of time in the International System of Units. Since 130 Resolution 1 of the 13th CGPM on 1967-10-13 [CGPM] the second is 131 defined as the duration of 9,192,631,770 cycles of microwave 132 radiation absorbed or emitted by the hyperfine transition of 133 cesium-133 atoms in their ground state undisturbed by external 134 fields, but this definition was not in practical use for civil 135 time until 1972-01-01. Prior to 1972-01-01 civil time was based 136 on Universal Time which was measured by observations of the 137 rotation of the earth, and the practical definition of the second 138 was 1/86400 of the mean solar day. 140 minute A period of time of 60 seconds. However, see also the 141 restrictions in section Section 5.7 and Appendix C for how leap 142 seconds are denoted within minutes. 144 hour A period of time of 60 minutes. 146 day Starting 1972-01-01 a duration of 86400 SI seconds for the UTC 147 time scale. In other contexts the duration of one mean solar day 148 as agreed internationally by the 1884 International Meridian 149 Conference and measured using Universal Time. 151 leap year In the proleptic Gregorian calendar, a year which has 366 152 days. A leap year is a year whose number is divisible by four an 153 integral number of times, except that if it is a centennial year 154 (i.e. divisible by one hundred) it shall also be divisible by four 155 hundred an integral number of times. 157 ABNF Augmented Backus-Naur Form, a format used to represent 158 permissible strings in a protocol or language, as defined in 159 [RFC2234]. 161 Email Date/Time Format The date/time format used by Internet Mail as 162 defined by [RFC2822]. 164 Internet Date/Time Format The date/time format defined in section 5 165 of this document. 167 Timestamp This term is used in this document to refer to an 168 unambiguous representation of some instant in time. 170 Z A suffix which, when applied to a time, denotes a UTC offset of 171 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 172 representation of the letter "Z". 174 For more information about time scales, see Appendix E of [RFC1305], 175 Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF]. 177 3. Two Digit Years 179 The use of 2 (and 3) digit years was allowed but deprecated in 180 [RFC3339], the predecessor of this document. 182 The use of such a format is no longer allowed, and implementations 183 should use either a standard 4-digit year or the extended 6-digit 184 value with a sign. 186 4. Local Time 187 4.1. Coordinated Universal Time (UTC) 189 Because the daylight saving rules for local time zones are so 190 convoluted and can change based on local law at unpredictable times, 191 true interoperability is best achieved by using Coordinated Universal 192 Time (UTC). This specification does not cater to local time zone 193 rules. 195 4.2. Local Offsets 197 The offset between local time and UTC is often useful information. 198 For example, in electronic mail ([RFC2822]) the local offset provides 199 a useful heuristic to determine the probability of a prompt response. 200 Attempts to label local offsets with alphabetic strings have resulted 201 in poor interoperability in the past [RFC1123]. As a result, 202 [RFC2822] has made numeric offsets mandatory. 204 Numeric offsets are calculated as "local time minus UTC". So the 205 equivalent time in UTC can be determined by subtracting the offset 206 from the local time. For example, "18:50:00-04:00" is the same time 207 as "22:50:00Z". (This example shows negative offsets handled by 208 adding the absolute value of the offset.) 210 Numeric offsets may differ from UTC by any number of seconds, or even 211 a fraction of seconds. This can be easily represented by including 212 an optional seconds value in the offset, which may further optionally 213 include a fraction of seconds behind a decimal point, for example 214 "+12:34:56.789". This is especially useful in the case of certain 215 historical time zones. 217 4.3. Unknown Local Offset Convention 219 If the time in UTC is known, but the offset to local time is unknown, 220 this can be represented with an offset of "-00:00". This differs 221 semantically from an offset of "Z" or "+00:00", which imply that UTC 222 is the preferred reference point for the specified time. RFC2822 223 [RFC2822] describes a similar convention for email. 225 4.4. Unqualified Local Time 227 A number of devices currently connected to the Internet run their 228 internal clocks in local time and are unaware of UTC. While the 229 Internet does have a tradition of accepting reality when creating 230 specifications, this should not be done at the expense of 231 interoperability. Since interpretation of an unqualified local time 232 zone will fail in approximately 23/24 of the globe, the 233 interoperability problems of unqualified local time are deemed 234 unacceptable for the Internet. Systems that are configured with a 235 local time, are unaware of the corresponding UTC offset, and depend 236 on time synchronization with other Internet systems, MUST use a 237 mechanism that ensures correct synchronization with UTC. Some 238 suitable mechanisms are: 240 * Use Network Time Protocol [RFC1305] to obtain the time in UTC. 242 * Use another host in the same local time zone as a gateway to the 243 Internet. This host MUST correct unqualified local times that are 244 transmitted to other hosts. 246 * Prompt the user for the local time zone and daylight saving rule 247 settings. 249 5. Date and Time format 251 This section discusses desirable qualities of date and time formats 252 and defines a profile of ISO 8601 for use in Internet protocols. 254 5.1. Ordering 256 If date and time components are ordered from least precise to most 257 precise, then a useful property is achieved. Assuming that the time 258 zones of the dates and times are the same (e.g., all in UTC), 259 expressed using the same string (e.g., all "Z" or all "+00:00"), and 260 all times have the same number of fractional second digits then the 261 date and time strings may be sorted as strings (e.g., using the 262 "strcmp()" function in C) and a time-ordered sequence will result. 263 The presence of optional punctuation would violate this 264 characteristic. 266 5.2. Human Readability 268 Human readability has proved to be a valuable feature of Internet 269 protocols. Human readable protocols greatly reduce the costs of 270 debugging since telnet often suffices as a test client and network 271 analyzers need not be modified with knowledge of the protocol. On 272 the other hand, human readability sometimes results in 273 interoperability problems. For example, the date format "10/11/1996" 274 is completely unsuitable for global interchange because it is 275 interpreted differently in different countries. In addition, the 276 date format in (RFC822) has resulted in interoperability problems 277 when people assumed any text string was permitted and translated the 278 three letter abbreviations to other languages or substituted date 279 formats which were easier to generate (e.g. the format used by the C 280 function "ctime"). For this reason, a balance must be struck between 281 human readability and interoperability. 283 Because no date and time format is readable according to the 284 conventions of all countries, Internet clients SHOULD be prepared to 285 transform dates into a display format suitable for the locality. 286 This may include translating UTC to local time. 288 5.3. Rarely Used Options 290 A format which includes rarely used options is likely to cause 291 interoperability problems. This is because rarely used options are 292 less likely to be used in alpha or beta testing, so bugs in parsing 293 are less likely to be discovered. Rarely used options should be made 294 mandatory or omitted for the sake of interoperability whenever 295 possible. 297 5.4. Redundant Information 299 If a date/time format includes redundant information, that introduces 300 the possibility that the redundant information will not correlate. 301 For example, including the day of the week in a date/time format 302 introduces the possibility that the day of week is incorrect but the 303 date is correct, or vice versa. Since it is not difficult to compute 304 the day of week from a date (see Appendix A), the day of week should 305 not be included in a date/time format. 307 5.5. Simplicity 309 The complete set of date and time formats specified in ISO 8601 310 [ISO8601] is quite complex in an attempt to provide multiple 311 representations and partial representations. Internet protocols have 312 somewhat different requirements and simplicity has proved to be an 313 important characteristic. In addition, Internet protocols usually 314 need complete specification of data in order to achieve true 315 interoperability. Therefore, the complete grammar for ISO 8601 is 316 deemed too complex for most Internet protocols. 318 The following section defines a profile of ISO 8601 for use on the 319 Internet. It is a conformant subset of the ISO 8601 extended format. 320 Simplicity is achieved by making most fields and punctuation 321 mandatory. 323 5.6. Internet Date/Time Format 325 The following profile of [ISO8601] dates SHOULD be used in new 326 protocols on the Internet. This is specified using the syntax 327 description notation defined in [RFC2234]. 329 date-year = 4DIGIT / ("+" / "-") 6DIGIT 330 date-month = 2DIGIT ; 01-12 331 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 332 date-full = date-year "-" date-month "-" date-mday 334 time-hour = 2DIGIT ; 00-23 335 time-minute = 2DIGIT ; 00-59 336 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules 337 time-secfrac = "." 1*DIGIT 338 time-partial = time-hour ":" time-minute ":" time-second [time-secfrac] 339 time-numoffset = ("+" / "-") time-partial 340 time-offset = "Z" / time-numoffset 341 time-full = time-partial time-offset 343 date-time = date-full "T" time-full 345 Figure 1 347 | NOTE 1: Per [RFC2234] and ISO8601, the "T" and "Z" characters 348 | in this syntax may alternatively be lower case "t" or "z" 349 | respectively. 351 This date/time format may be used in some environments or contexts 352 that distinguish between the upper- and lower-case letters 'A'-'Z' 353 and 'a'-'z' (e.g. XML). Specifications that use this format in such 354 environments MAY further limit the date/time syntax so that the 355 letters 'T' and 'Z' used in the date/time syntax must always be upper 356 case. Applications that generate this format SHOULD use upper case 357 letters. 359 | NOTE 2: ISO 8601 defines date and time separated by "T". 360 | Applications using this syntax may choose, for the sake of 361 | readability, to specify a full-date and full-time separated by 362 | (say) a space character. 364 5.7. Restrictions 366 The grammar element date-mday represents the day number within the 367 current month. The maximum value varies based on the month and year 368 as follows: 370 +==============+=====================+============================+ 371 | Month Number | Month/Year | Maximum value of date-mday | 372 +==============+=====================+============================+ 373 | 01 | January | 31 | 374 +--------------+---------------------+----------------------------+ 375 | 02 | February, normal | 28 | 376 +--------------+---------------------+----------------------------+ 377 | 02 | February, leap year | 29 | 378 +--------------+---------------------+----------------------------+ 379 | 03 | March | 31 | 380 +--------------+---------------------+----------------------------+ 381 | 04 | April | 30 | 382 +--------------+---------------------+----------------------------+ 383 | 05 | May | 31 | 384 +--------------+---------------------+----------------------------+ 385 | 06 | June | 30 | 386 +--------------+---------------------+----------------------------+ 387 | 07 | July | 31 | 388 +--------------+---------------------+----------------------------+ 389 | 08 | August | 31 | 390 +--------------+---------------------+----------------------------+ 391 | 09 | September | 30 | 392 +--------------+---------------------+----------------------------+ 393 | 10 | October | 31 | 394 +--------------+---------------------+----------------------------+ 395 | 11 | November | 30 | 396 +--------------+---------------------+----------------------------+ 397 | 12 | December | 31 | 398 +--------------+---------------------+----------------------------+ 400 Table 1: Days in each month 402 Appendix B contains sample C code to determine if a year is a leap 403 year. 405 The grammar element time-second may have the value "60" at the end of 406 months in which a leap second occurs - to date: June (XXXX-06- 407 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix C for 408 a table of leap seconds. It is also possible for a leap second to be 409 subtracted, at which times the maximum value of time-second is "58". 410 At all other times the maximum value of time-second is "59". 411 Further, in time zones other than "Z", the leap second point is 412 shifted by the zone offset (so it happens at the same instant around 413 the globe). 415 Leap seconds cannot be predicted far into the future. The 416 International Earth Rotation Service publishes bulletins [IERS] that 417 announce leap seconds with a few weeks' warning. Applications should 418 not generate timestamps involving inserted leap seconds until after 419 the leap seconds are announced. 421 Although ISO 8601 permits the hour to be "24", this profile of ISO 422 8601 only allows values between "00" and "23" for the hour in order 423 to reduce confusion. 425 5.8. Examples 427 Here are some examples of Internet date/time format. 429 1985-04-12T23:20:50.52Z 431 Figure 2 433 This represents 20 minutes and 50.52 seconds after the 23rd hour of 434 April 12th, 1985 in UTC. 436 +001985-04-12T23:20:50.52Z 438 Figure 3 440 This represents the same instant as the previous example but with the 441 expanded 6-digit year format. 443 1996-12-19T16:39:57-08:00 445 Figure 4 447 This represents 39 minutes and 57 seconds after the 16th hour of 448 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 449 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z 450 in UTC. 452 1990-12-31T23:59:60Z 454 Figure 5 456 This represents the leap second inserted at the end of 1990. 458 1990-12-31T15:59:60-08:00 460 Figure 6 462 This represents the same leap second in Pacific Standard Time, 8 463 hours behind UTC. 465 1937-01-01T12:00:27.87+00:19:32.130 467 Figure 7 469 This represents the same instant of time as noon, January 1, 1937, 470 Netherlands time. Standard time in the Netherlands was exactly 19 471 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 472 1937-06-30. 474 6. Security Considerations 476 Since the local time zone of a site may be useful for determining a 477 time when systems are less likely to be monitored and might be more 478 susceptible to a security probe, some sites may wish to emit times in 479 UTC only. Others might consider this to be loss of useful 480 functionality at the hands of paranoia. 482 7. Normative references 484 [RFC2822] Resnick, P., Ed., "Internet Message Format", IETF RFC 485 2822, IETF RFC 2822, DOI 10.17487/RFC2822, April 2001, 486 . 488 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 489 Specifications: ABNF", IETF RFC 2234, IETF RFC 2234, 490 DOI 10.17487/RFC2234, November 1997, 491 . 493 [RFC1123] Braden, R., Ed., "Requirements for Internet 494 Hosts — Application and Support", IETF RFC 1123, IETF RFC 495 1123, DOI 10.17487/RFC1123, October 1989, 496 . 498 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 499 Specification, Implementation and Analysis", IETF RFC 500 1305, IETF RFC 1305, DOI 10.17487/RFC1305, March 1992, 501 . 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", IETF RFC 2119, IETF RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 509 Languages", IETF RFC 5646, IETF RFC 5646, 510 DOI 10.17487/RFC5646, September 2009, 511 . 513 [RFC2026] Bradner, S., "The Internet Standards Process — Revision 514 3", IETF RFC 2026, IETF RFC 2026, DOI 10.17487/RFC2026, 515 October 1996, . 517 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 518 the IETF Standards Process", IETF RFC 2028, IETF RFC 2028, 519 DOI 10.17487/RFC2028, October 1996, 520 . 522 8. Bibliography 524 [ISO8601] International Organization for Standardization, "Data 525 elements and interchange formats", ISO 8601:1988, June 526 1988, . 528 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 529 Timestamps", IETF RFC 3339, IETF RFC 3339, 530 DOI 10.17487/RFC3339, July 2002, 531 . 533 [ISO8601-2000] 534 International Organization for Standardization, "Data 535 elements and interchange formats", ISO 8601:2000, December 536 2000, . 538 [ITU-R-TF] "", ITU-R TF.460-6. 540 [CGPM] "Resolution 1 of the 13th CGPM, 1967". 542 [ZELLER] "Zeller, Chr. Kalender-Formeln. Acta Math. 9 (1887), 543 131—136. doi:10.1007/BF02406733". 545 [IERS] "International Earth Rotation Service Bulletins". 547 Appendix A. Day of the Week 549 The following is a sample C subroutine loosely based on Zeller's 550 Congruence [ZELLER] which may be used to obtain the day of the week 551 for dates on or after 0000-03-01: 553 char *day_of_week(int day, int month, int year) 554 { 555 int cent; 556 char *dayofweek[] = { 557 "Sunday", "Monday", "Tuesday", "Wednesday", 558 "Thursday", "Friday", "Saturday" 559 }; 561 /* adjust months so February is the last one */ 562 month -= 2; 563 if (month < 1) { 564 month += 12; 565 --year; 566 } 567 /* split by century */ 568 cent = year / 100; 569 year %= 100; 570 return (dayofweek[((26 * month - 2) / 10 + day + year 571 + year / 4 + cent / 4 + 5 * cent) % 7]); 572 } 574 Figure 8 576 Appendix B. Leap Years 578 Here is a sample C subroutine to calculate if a year is a leap year: 580 /* This returns non-zero if year is a leap year. Must use 4 digit 581 year. 582 */ 583 int leap_year(int year) 584 { 585 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 586 } 588 Figure 9 590 Appendix C. Leap Seconds 592 In 1970 CCIR Recommendation 460 produced international agreement that 593 starting on 1972-01-01 radio broadcast time signals should provide SI 594 seconds with occasional leaps of 1 SI second as necessary to agree 595 with Universal Time. The time scale in radio broadcasts became known 596 as UTC, and the current version of that recommendation is [ITU-R-TF]. 597 Since 1988 IERS has the responsibility for announcing when leap 598 seconds will be introduced into UTC 599 (https://www.iers.org/SharedDocs/Publikationen/EN/IERS/Documents/ 600 IERS_Leap_Seconds.pdf?__blob=publicationFile&v=1). Further 601 information about leap seconds can be found at the US Navy 602 Oceanography Portal (https://www.usno.navy.mil/USNO/time/master- 603 clock/leap-seconds). In particular, it notes that: 605 | The decision to introduce a leap second in UTC is the 606 | responsibility of the International Earth Rotation Service [IERS]. 607 | According to the CCIR Recommendation, first preference is given to 608 | the opportunities at the end of December and June, and second 609 | preference to those at the end of March and September. 611 When required, insertion of a leap second occurs as an extra second 612 at the end of a day in UTC, represented by a timestamp of the form 613 YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all 614 time zones, so that time zone relationships are not affected. See 615 section Section 5.8 for some examples of leap second times. 617 The following table is an excerpt from the table maintained by the 618 IERS. The source data are located at the Earth Orientation 619 Parameters Product Centre at Observatoire de Paris 620 (https://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=en). 622 For dates after the initial adjustment on 1972-01-01 this table shows 623 the date of the leap second, and the difference between the time 624 scale TAI (which is not adjusted by leap seconds) and UTC after that 625 leap second. 627 +============+=============================+ 628 | UTC Date | TAI - UTC After Leap Second | 629 +============+=============================+ 630 | 1972-06-30 | 11 | 631 +------------+-----------------------------+ 632 | 1972-12-31 | 12 | 633 +------------+-----------------------------+ 634 | 1973-12-31 | 13 | 635 +------------+-----------------------------+ 636 | 1974-12-31 | 14 | 637 +------------+-----------------------------+ 638 | 1975-12-31 | 15 | 639 +------------+-----------------------------+ 640 | 1976-12-31 | 16 | 641 +------------+-----------------------------+ 642 | 1977-12-31 | 17 | 643 +------------+-----------------------------+ 644 | 1978-12-31 | 18 | 645 +------------+-----------------------------+ 646 | 1979-12-31 | 19 | 647 +------------+-----------------------------+ 648 | 1981-06-30 | 20 | 649 +------------+-----------------------------+ 650 | 1982-06-30 | 21 | 651 +------------+-----------------------------+ 652 | 1983-06-30 | 22 | 653 +------------+-----------------------------+ 654 | 1985-06-30 | 23 | 655 +------------+-----------------------------+ 656 | 1987-12-31 | 24 | 657 +------------+-----------------------------+ 658 | 1989-12-31 | 25 | 659 +------------+-----------------------------+ 660 | 1990-12-31 | 26 | 661 +------------+-----------------------------+ 662 | 1992-06-30 | 27 | 663 +------------+-----------------------------+ 664 | 1993-06-30 | 28 | 665 +------------+-----------------------------+ 666 | 1994-06-30 | 29 | 667 +------------+-----------------------------+ 668 | 1995-12-31 | 30 | 669 +------------+-----------------------------+ 670 | 1997-06-30 | 31 | 671 +------------+-----------------------------+ 672 | 1998-12-31 | 32 | 673 +------------+-----------------------------+ 674 | 2005-12-31 | 33 | 675 +------------+-----------------------------+ 676 | 2008-12-31 | 34 | 677 +------------+-----------------------------+ 678 | 2012-06-30 | 35 | 679 +------------+-----------------------------+ 680 | 2015-06-30 | 36 | 681 +------------+-----------------------------+ 682 | 2016-12-31 | 37 | 683 +------------+-----------------------------+ 685 Table 2: Historic leap seconds 687 Author's Address 689 Ujjwal Sharma 690 Igalia, S.L. 692 Email: ryzokuken@igalia.com