idnits 2.17.1 draft-ryzokuken-datetime-extended-00.txt: -(526): 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 is 1 instance 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 (11 January 2021) is 1202 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 542, but not defined == Missing Reference: 'RFC3339' is mentioned on line 546, but not defined ** 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) Summary: 5 errors (**), 0 flaws (~~), 4 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) 11 January 2021 5 Intended status: Standards Track 6 Expires: 15 July 2021 8 Date and Time on the Internet: Timestamps with additional information 9 draft-ryzokuken-datetime-extended-00 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 and a calendaring system. 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 15 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 9 67 5.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. Normative references . . . . . . . . . . . . . . . . . . . . 12 70 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Day of the Week . . . . . . . . . . . . . . . . . . 13 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 extension to an Internet profile of the 85 [ISO8601] standard for representation of dates and times using the 86 proleptic Gregorian calendar alongside any additional information. 87 Any dates and times that are required to be handled in a different 88 calendar system need to include the ID of the calendar which can be 89 handle by the implementations approximately. In the absence of a 90 calendar ID, the proleptic Gregorian calendar system is assumed. 92 There are many ways in which date and time values might appear in 93 Internet protocols: this document focuses on just one common usage, 94 viz. timestamps for Internet protocol events. This limited 95 consideration has the following consequences: 97 * All dates and times are assumed to be in the "current era", 98 somewhere between 0000AD and 9999AD. 100 * All times expressed have a stated relationship (offset) to 101 Coordinated Universal Time (UTC). Certain applications require 102 the presence of a time zone in order to perform scheduling as well 103 as handle Daylight Savings Time transitions properly. In that 104 case, an optional time zone ID may be included. 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 by the Bureau 120 International des Poids et Mesures (BIPM). 122 second A basic unit of measurement of time in the International 123 System of Units. It is defined as the duration of 9,192,631,770 124 cycles of microwave light absorbed or emitted by the hyperfine 125 transition of cesium-133 atoms in their ground state undisturbed 126 by external fields. 128 minute A period of time of 60 seconds. However, see also the 129 restrictions in section Section 5.7 and Appendix C for how leap 130 seconds are denoted within minutes. 132 hour A period of time of 60 minutes. 134 day A period of time of 24 hours. 136 leap year In the proleptic Gregorian calendar, a year which has 366 137 days. A leap year is a year whose number is divisible by four an 138 integral number of times, except that if it is a centennial year 139 (i.e. divisible by one hundred) it shall also be divisible by four 140 hundred an integral number of times. 142 ABNF Augmented Backus-Naur Form, a format used to represent 143 permissible strings in a protocol or language, as defined in 144 [RFC2234]. 146 Email Date/Time Format The date/time format used by Internet Mail as 147 defined by [RFC2822]. 149 Internet Date/Time Format The date/time format defined in section 5 150 of this document. 152 Timestamp This term is used in this document to refer to an 153 unambiguous representation of some instant in time. 155 Z A suffix which, when applied to a time, denotes a UTC offset of 156 00:00; often spoken "Zulu" from the ICAO phonetic alphabet 157 representation of the letter "Z". 159 Time Zone A time zone that is a included in the Time Zone Database 160 (often called "tz" or "zoneinfo") maintained by IANA. 162 Calendar A calendar that is included in the Unicode CLDR data as a 163 valid calendar for use in BCP47 language tags. 165 For more information about time scales, see Appendix E of [RFC1305], 166 Section 3 of [ISO8601], and the appropriate ITU documents (ITU-R-TF). 168 3. Two Digit Years 170 The use of 2 (and 3) digit years was allowed but deprecated in 171 [RFC3339], the predecessor of this document. 173 The use of such a format is no longer allowed, and implementations 174 should use either a standard 4-digit year or the extended 6-digit 175 value with a sign. 177 4. Local Time 179 4.1. Coordinated Universal Time (UTC) 181 Because the daylight saving rules for local time zones are so 182 convoluted and can change based on local law at unpredictable times, 183 true interoperability is best achieved by using Coordinated Universal 184 Time (UTC). This specification by itself does not cater to local 185 time zone rules. However, certain implementations may be expected 186 to. For these situations, a timestamp may additionally include a 187 local time zone that the implementations can take into account. 189 4.2. Local Offsets 191 The offset between local time and UTC is often useful information. 192 For example, in electronic mail (RFC2822, [RFC2822]) the local offset 193 provides a useful heuristic to determine the probability of a prompt 194 response. Attempts to label local offsets with alphabetic strings 195 have resulted in poor interoperability in the past [RFC1123]. As a 196 result, RFC2822 [RFC2822] has made numeric offsets mandatory. 198 Numeric offsets are calculated as "local time minus UTC". So the 199 equivalent time in UTC can be determined by subtracting the offset 200 from the local time. For example, "18:50:00-04:00" is the same time 201 as "22:50:00Z". (This example shows negative offsets handled by 202 adding the absolute value of the offset.) 204 Numeric offsets may differ from UTC by any number of seconds, or even 205 a fraction of seconds. This can be easily represented by including 206 an optional seconds value in the offset, which may further optionally 207 include a fraction of seconds behind a decimal point, for example 208 "+12:34:56.789". This is especially useful in the case of certain 209 historical time zones. 211 4.3. Unknown Local Offset Convention 213 If the time in UTC is known, but the offset to local time is unknown, 214 this can be represented with an offset of "-00:00". This differs 215 semantically from an offset of "Z" or "+00:00", which imply that UTC 216 is the preferred reference point for the specified time. RFC2822 217 [RFC2822] describes a similar convention for email. 219 4.4. Unqualified Local Time 221 A number of devices currently connected to the Internet run their 222 internal clocks in local time and are unaware of UTC. While the 223 Internet does have a tradition of accepting reality when creating 224 specifications, this should not be done at the expense of 225 interoperability. Since interpretation of an unqualified local time 226 zone will fail in approximately 23/24 of the globe, the 227 interoperability problems of unqualified local time are deemed 228 unacceptable for the Internet. Systems that are configured with a 229 local time, are unaware of the corresponding UTC offset, and depend 230 on time synchronization with other Internet systems, MUST use a 231 mechanism that ensures correct synchronization with UTC. Some 232 suitable mechanisms are: 234 * Use Network Time Protocol [RFC1305] to obtain the time in UTC. 236 * Use another host in the same local time zone as a gateway to the 237 Internet. This host MUST correct unqualified local times that are 238 transmitted to other hosts. 240 * Prompt the user for the local time zone and daylight saving rule 241 settings. 243 5. Date and Time format 245 This section discusses desirable qualities of date and time formats 246 and defines a format that extends the profile of ISO 8601 for use in 247 Internet protocols. 249 5.1. Ordering 251 If date and time components are ordered from least precise to most 252 precise, then a useful property is achieved. Assuming that the time 253 zones of the dates and times are the same (e.g., all in UTC), 254 expressed using the same string (e.g., all "Z" or all "+00:00"), all 255 times have the same number of fractional second digits, and they all 256 have the same suffix (or none), then the date and time strings may be 257 sorted as strings (e.g., using the "strcmp()" function in C) and a 258 time-ordered sequence will result. The presence of optional 259 punctuation would violate this characteristic. 261 5.2. Human Readability 263 Human readability has proved to be a valuable feature of Internet 264 protocols. Human readable protocols greatly reduce the costs of 265 debugging since telnet often suffices as a test client and network 266 analyzers need not be modified with knowledge of the protocol. On 267 the other hand, human readability sometimes results in 268 interoperability problems. For example, the date format "10/11/1996" 269 is completely unsuitable for global interchange because it is 270 interpreted differently in different countries. In addition, the 271 date format in (RFC822) has resulted in interoperability problems 272 when people assumed any text string was permitted and translated the 273 three letter abbreviations to other languages or substituted date 274 formats which were easier to generate (e.g. the format used by the C 275 function "ctime"). For this reason, a balance must be struck between 276 human readability and interoperability. 278 Because no date and time format is readable according to the 279 conventions of all countries, Internet clients SHOULD be prepared to 280 transform dates into a display format suitable for the locality. 281 This may include translating UTC to local time as well as converting 282 from the Gregorian calendar to the viewer's preferred calendar. 284 5.3. Rarely Used Options 286 A format which includes rarely used options is likely to cause 287 interoperability problems. This is because rarely used options are 288 less likely to be used in alpha or beta testing, so bugs in parsing 289 are less likely to be discovered. Rarely used options should be made 290 mandatory or omitted for the sake of interoperability whenever 291 possible. 293 5.4. Redundant Information 295 If a date/time format includes redundant information, that introduces 296 the possibility that the redundant information will not correlate. 297 For example, including the day of the week in a date/time format 298 introduces the possibility that the day of week is incorrect but the 299 date is correct, or vice versa. Since it is not difficult to compute 300 the day of week from a date (see Appendix A), the day of week should 301 not be included in a date/time format. 303 5.5. Simplicity 305 The complete set of date and time formats specified in ISO 8601 306 [ISO8601] is quite complex in an attempt to provide multiple 307 representations and partial representations. Internet protocols have 308 somewhat different requirements and simplicity has proved to be an 309 important characteristic. In addition, Internet protocols usually 310 need complete specification of data in order to achieve true 311 interoperability. Therefore, the complete grammar for ISO 8601 is 312 deemed too complex for most Internet protocols. 314 The following section defines a format that in an extension of a 315 profile of ISO 8601 for use on the Internet. It is a conformant 316 subset of the ISO 8601 extended format with additional information 317 optionally suffixed. Simplicity is achieved by making most fields 318 and punctuation mandatory. 320 5.6. Internet Date/Time Format 322 The following extension of a profile of [ISO8601] dates SHOULD be 323 used in new protocols on the Internet. This is specified using the 324 syntax description notation defined in [RFC2234]. 326 date-year = 4DIGIT / ("+" / "-") 6DIGIT 327 date-month = 2DIGIT ; 01-12 328 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year 329 date-full = date-year "-" date-month "-" date-mday 331 time-hour = 2DIGIT ; 00-23 332 time-minute = 2DIGIT ; 00-59 333 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules 334 time-secfrac = "." 1*DIGIT 335 time-partial = time-hour ":" time-minute ":" time-second [time-secfrac] 336 time-numoffset = ("+" / "-") time-partial 337 time-offset = "Z" / time-numoffset 338 time-full = time-partial time-offset 340 time-zone-char = ALPHA / "." / "_" 341 time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".." 342 time-zone-id = time-zone-part *("/" time-zone-part) 343 time-zone = "[" time-zone-id "]" 345 calendar-part = 3*8(ALPHA / DIGIT) 346 calendar-id = calendar-part *("-" calendar-part) 347 calendar = "[c=" calendar-id "]" 349 suffix-part = "[" 1*ALPHA "=" 1*VCHAR "]" 350 suffix = [time-zone] [calendar] *suffix-part 352 date-time = date-full "T" time-full suffix 354 Figure 1 356 | NOTE 1: Per [RFC2234] and ISO8601, the "T" and "Z" characters 357 | in this syntax may alternatively be lower case "t" or "z" 358 | respectively. 360 This date/time format may be used in some environments or contexts 361 that distinguish between the upper- and lower-case letters 'A'-'Z' 362 and 'a'-'z' (e.g. XML). Specifications that use this format in such 363 environments MAY further limit the date/time syntax so that the 364 letters 'T' and 'Z' used in the date/time syntax must always be upper 365 case. Applications that generate this format SHOULD use upper case 366 letters. 368 | NOTE 2: ISO 8601 defines date and time separated by "T". 369 | Applications using this syntax may choose, for the sake of 370 | readability, to specify a full-date and full-time separated by 371 | (say) a space character. 373 5.7. Restrictions 375 The grammar element date-mday represents the day number within the 376 current month. The maximum value varies based on the month and year 377 as follows: 379 +==============+=====================+============================+ 380 | Month Number | Month/Year | Maximum value of date-mday | 381 +==============+=====================+============================+ 382 | 01 | January | 31 | 383 +--------------+---------------------+----------------------------+ 384 | 02 | February, normal | 28 | 385 +--------------+---------------------+----------------------------+ 386 | 02 | February, leap year | 29 | 387 +--------------+---------------------+----------------------------+ 388 | 03 | March | 31 | 389 +--------------+---------------------+----------------------------+ 390 | 04 | April | 30 | 391 +--------------+---------------------+----------------------------+ 392 | 05 | May | 31 | 393 +--------------+---------------------+----------------------------+ 394 | 06 | June | 30 | 395 +--------------+---------------------+----------------------------+ 396 | 07 | July | 31 | 397 +--------------+---------------------+----------------------------+ 398 | 08 | August | 31 | 399 +--------------+---------------------+----------------------------+ 400 | 09 | September | 30 | 401 +--------------+---------------------+----------------------------+ 402 | 10 | October | 31 | 403 +--------------+---------------------+----------------------------+ 404 | 11 | November | 30 | 405 +--------------+---------------------+----------------------------+ 406 | 12 | December | 31 | 407 +--------------+---------------------+----------------------------+ 409 Table 1: Days in each month 411 Appendix B contains sample C code to determine if a year is a leap 412 year. 414 The grammar element time-second may have the value "60" at the end of 415 months in which a leap second occurs - to date: June (XXXX-06- 416 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix C for 417 a table of leap seconds. It is also possible for a leap second to be 418 subtracted, at which times the maximum value of time-second is "58". 419 At all other times the maximum value of time-second is "59". 420 Further, in time zones other than "Z", the leap second point is 421 shifted by the zone offset (so it happens at the same instant around 422 the globe). 424 Leap seconds cannot be predicted far into the future. The 425 International Earth Rotation Service publishes bulletins (IERS) that 426 announce leap seconds with a few weeks' warning. Applications should 427 not generate timestamps involving inserted leap seconds until after 428 the leap seconds are announced. 430 Although ISO 8601 permits the hour to be "24", this extension of a 431 profile of ISO 8601 only allows values between "00" and "23" for the 432 hour in order to reduce confusion. 434 5.8. Examples 436 Here are some examples of Internet date/time format. 438 1985-04-12T23:20:50.52Z 440 Figure 2 442 This represents 20 minutes and 50.52 seconds after the 23rd hour of 443 April 12th, 1985 in UTC. 445 +001985-04-12T23:20:50.52Z 447 Figure 3 449 This represents the same instant as the previous example but with the 450 expanded 6-digit year format. 452 1996-12-19T16:39:57-08:00 454 Figure 4 456 This represents 39 minutes and 57 seconds after the 16th hour of 457 December 19th, 1996 with an offset of -08:00 from UTC (Pacific 458 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z 459 in UTC. 461 1996-12-19T16:39:57-08:00[America/Los_Angeles] 462 Figure 5 464 This represents the exact same instant as the previous example but 465 additionally specifies the human time zone associated with it for 466 time zone aware implementations to take into account. 468 1990-12-31T23:59:60Z 470 Figure 6 472 This represents the leap second inserted at the end of 1990. 474 1990-12-31T15:59:60-08:00 476 Figure 7 478 This represents the same leap second in Pacific Standard Time, 8 479 hours behind UTC. 481 1937-01-01T12:00:27.87+00:19:32.130 483 Figure 8 485 This represents the same instant of time as noon, January 1, 1937, 486 Netherlands time. Standard time in the Netherlands was exactly 19 487 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 488 1937-06-30. 490 1937-01-01T12:00:27.87+00:19:32.130[c=japanese] 492 Figure 9 494 This represents the exact same instant as the previous example but 495 additionally specifies the human calendar associated with it for 496 calendar aware implementations to take into account. 498 1937-01-01T12:00:27.87+00:19:32.130[foo=bar][baz=bat] 500 Figure 10 502 This timestamp utilizes the generalized format to declare two 503 additional pieces of information in the suffix that can be 504 interpreted by any compatible implementations and ignored otherwise. 506 6. Security Considerations 508 Since the local time zone of a site may be useful for determining a 509 time when systems are less likely to be monitored and might be more 510 susceptible to a security probe, some sites may wish to emit times in 511 UTC only. Others might consider this to be loss of useful 512 functionality at the hands of paranoia. 514 7. Normative references 516 [RFC2822] Resnick, P., Ed., "Internet Message Format", IETF RFC 517 2822, IETF RFC 2822, DOI 10.17487/RFC2822, April 2001, 518 . 520 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 521 Specifications: ABNF", IETF RFC 2234, IETF RFC 2234, 522 DOI 10.17487/RFC2234, November 1997, 523 . 525 [RFC1123] Braden, R., Ed., "Requirements for Internet 526 Hosts — Application and Support", IETF RFC 1123, IETF RFC 527 1123, DOI 10.17487/RFC1123, October 1989, 528 . 530 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 531 Specification, Implementation and Analysis", IETF RFC 532 1305, IETF RFC 1305, DOI 10.17487/RFC1305, March 1992, 533 . 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", IETF RFC 2119, IETF RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 8. Bibliography 542 [ISO8601] International Organization for Standardization, "Data 543 elements and interchange formats", ISO 8601:1988, June 544 1988, . 546 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 547 Timestamps", IETF RFC 3339, IETF RFC 3339, 548 DOI 10.17487/RFC3339, July 2002, 549 . 551 Appendix A. Day of the Week 553 The following is a sample C subroutine loosely based on Zeller's 554 Congruence (ZELLER) which may be used to obtain the day of the week 555 for dates on or after 0000-03-01: 557 char *day_of_week(int day, int month, int year) 558 { 559 int cent; 560 char *dayofweek[] = { 561 "Sunday", "Monday", "Tuesday", "Wednesday", 562 "Thursday", "Friday", "Saturday" 563 }; 565 /* adjust months so February is the last one */ 566 month -= 2; 567 if (month < 1) { 568 month += 12; 569 --year; 570 } 571 /* split by century */ 572 cent = year / 100; 573 year %= 100; 574 return (dayofweek[((26 * month - 2) / 10 + day + year 575 + year / 4 + cent / 4 + 5 * cent) % 7]); 576 } 578 Figure 11 580 Appendix B. Leap Years 582 Here is a sample C subroutine to calculate if a year is a leap year: 584 /* This returns non-zero if year is a leap year. Must use 4 digit 585 year. 586 */ 587 int leap_year(int year) 588 { 589 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)); 590 } 592 Figure 12 594 Appendix C. Leap Seconds 596 Information about leap seconds can be found at the US Navy 597 Oceanography Portal (https://www.usno.navy.mil/USNO/time/master- 598 clock/leap-seconds). In particular, it notes that: 600 | The decision to introduce a leap second in UTC is the 601 | responsibility of the International Earth Rotation Service (IERS). 602 | According to the CCIR Recommendation, first preference is given to 603 | the opportunities at the end of December and June, and second 604 | preference to those at the end of March and September. 606 When required, insertion of a leap second occurs as an extra second 607 at the end of a day in UTC, represented by a timestamp of the form 608 YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all 609 time zones, so that time zone relationships are not affected. See 610 section Section 5.8 for some examples of leap second times. 612 The following table is an excerpt from the table maintained by the 613 United States Naval Observatory. The source data is located at the 614 US Navy Oceanography Portal (ftp://maia.usno.navy.mil/ser7/tai- 615 utc.dat). 617 This table shows the date of the leap second, and the difference 618 between the time standard TAI (which isn't adjusted by leap seconds) 619 and UTC after that leap second. 621 +============+=============================+ 622 | UTC Date | TAI - UTC After Leap Second | 623 +============+=============================+ 624 | 1972-06-30 | 11 | 625 +------------+-----------------------------+ 626 | 1972-12-31 | 12 | 627 +------------+-----------------------------+ 628 | 1973-12-31 | 13 | 629 +------------+-----------------------------+ 630 | 1974-12-31 | 14 | 631 +------------+-----------------------------+ 632 | 1975-12-31 | 15 | 633 +------------+-----------------------------+ 634 | 1976-12-31 | 16 | 635 +------------+-----------------------------+ 636 | 1977-12-31 | 17 | 637 +------------+-----------------------------+ 638 | 1978-12-31 | 18 | 639 +------------+-----------------------------+ 640 | 1979-12-31 | 19 | 641 +------------+-----------------------------+ 642 | 1981-06-30 | 20 | 643 +------------+-----------------------------+ 644 | 1982-06-30 | 21 | 645 +------------+-----------------------------+ 646 | 1983-06-30 | 22 | 647 +------------+-----------------------------+ 648 | 1985-06-30 | 23 | 649 +------------+-----------------------------+ 650 | 1987-12-31 | 24 | 651 +------------+-----------------------------+ 652 | 1989-12-31 | 25 | 653 +------------+-----------------------------+ 654 | 1990-12-31 | 26 | 655 +------------+-----------------------------+ 656 | 1992-06-30 | 27 | 657 +------------+-----------------------------+ 658 | 1993-06-30 | 28 | 659 +------------+-----------------------------+ 660 | 1994-06-30 | 29 | 661 +------------+-----------------------------+ 662 | 1995-12-31 | 30 | 663 +------------+-----------------------------+ 664 | 1997-06-30 | 31 | 665 +------------+-----------------------------+ 666 | 1998-12-31 | 32 | 667 +------------+-----------------------------+ 669 Table 2: Historic leap seconds 671 Author's Address 673 Ujjwal Sharma 674 Igalia, S.L. 676 Email: ryzokuken@igalia.com