PROPOSED STANDARD

Errata Exist

Network Working Group G. Klyne Request for Comments: 3339 Clearswift Corporation Category: Standards Track C. Newman Sun Microsystems July 2002 Date and Time on the Internet: Timestamps Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Table of Contents 1. Introduction ............................................ 2 2. Definitions ............................................. 3 3. Two Digit Years ......................................... 4 4. Local Time .............................................. 4 4.1. Coordinated Universal Time (UTC) ...................... 4 4.2. Local Offsets ......................................... 5 4.3. Unknown Local Offset Convention ....................... 5 4.4. Unqualified Local Time ................................ 5 5. Date and Time format .................................... 6 5.1. Ordering .............................................. 6 5.2. Human Readability ..................................... 6 5.3. Rarely Used Options ................................... 7 5.4. Redundant Information ................................. 7 5.5. Simplicity ............................................ 7 5.6. Internet Date/Time Format ............................. 8 5.7. Restrictions .......................................... 9 5.8. Examples ............................................. 10 6. References ............................................. 10 7. Security Considerations ................................ 11 Klyne, et. al. Standards Track [Page 1]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Appendix A. ISO 8601 Collected ABNF ....................... 12 Appendix B. Day of the Week ............................... 14 Appendix C. Leap Years .................................... 14 Appendix D. Leap Seconds ..............................,... 15 Acknowledgements .......................................... 17 Authors' Addresses ........................................ 17 Full Copyright Statement .................................. 18 1 . Introduction ISO8601] standard for representation of dates and times using the Gregorian calendar. There are many ways in which date and time values might appear in Internet protocols: this document focuses on just one common usage, viz. timestamps for Internet protocol events. This limited consideration has the following consequences: o All dates and times are assumed to be in the "current era", somewhere between 0000AD and 9999AD. o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.) o Timestamps can express times that occurred before the introduction of UTC. Such timestamps are expressed relative to universal time, using the best available practice at the stated time. o Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here. Klyne, et. al. Standards Track [Page 2]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 2 . Definitions RFC 2119 [RFC2119]. UTC Coordinated Universal Time as maintained by the Bureau International des Poids et Mesures (BIPM). second A basic unit of measurement of time in the International System of Units. It is defined as the duration of 9,192,631,770 cycles of microwave light absorbed or emitted by the hyperfine transition of cesium-133 atoms in their ground state undisturbed by external fields. minute A period of time of 60 seconds. However, see also the restrictions in section 5.7 and Appendix D for how leap seconds are denoted within minutes. hour A period of time of 60 minutes. day A period of time of 24 hours. leap year In the Gregorian calendar, a year which has 366 days. A leap year is a year whose number is divisible by four an integral number of times, except that if it is a centennial year (i.e. divisible by one hundred) it shall also be divisible by four hundred an integral number of times. ABNF Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [ABNF]. Email Date/Time Format The date/time format used by Internet Mail as defined by RFC 2822 [IMAIL-UPDATE]. Internet Date/Time Format The date format defined in section 5 of this document. Timestamp This term is used in this document to refer to an unambiguous representation of some instant in time. Z A suffix which, when applied to a time, denotes a UTC offset of 00:00; often spoken "Zulu" from the ICAO phonetic alphabet representation of the letter "Z". Klyne, et. al. Standards Track [Page 3]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 4.2 . Local Offsets RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response. Attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past [IMAIL], [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric offsets mandatory. Numeric offsets are calculated as "local time minus UTC". So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00-04:00 is the same time as 22:50:00Z. (This example shows negative offsets handled by adding the absolute value of the offset.) NOTE: Following ISO 8601, numeric offsets represent only time zones that differ from UTC by an integral number of minutes. However, many historical time zones differ from UTC by a non- integral number of minutes. To represent such historical time stamps exactly, applications must convert them to a representable time zone. 4.3 . Unknown Local Offset Convention RFC2822 [IMAIL-UPDATE] describes a similar convention for email. 4.4 . Unqualified Local Time NTP] to obtain the time in UTC. Klyne, et. al. Standards Track [Page 5]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 5 . Date and Time format 5.1 . Ordering 5.2 . Human Readability IMAIL] has resulted in interoperability problems when people assumed any text string was permitted and translated the three letter abbreviations to other languages or substituted date formats which were easier to generate (e.g. the format used by the C function ctime). For this reason, a balance must be struck between human readability and interoperability. Because no date and time format is readable according to the conventions of all countries, Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. This may include translating UTC to local time. Klyne, et. al. Standards Track [Page 6]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 5.3 . Rarely Used Options 5.4 . Redundant Information Appendix B), the day of week should not be included in a date/time format. 5.5 . Simplicity ISO8601] is quite complex in an attempt to provide multiple representations and partial representations. Appendix A contains an attempt to translate the complete syntax of ISO 8601 into ABNF. Internet protocols have somewhat different requirements and simplicity has proved to be an important characteristic. In addition, Internet protocols usually need complete specification of data in order to achieve true interoperability. Therefore, the complete grammar for ISO 8601 is deemed too complex for most Internet protocols. The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory. Klyne, et. al. Standards Track [Page 7]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 5.6 . Internet Date/Time Format ISO8601] dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in [ABNF]. date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively. This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters. NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. Klyne, et. al. Standards Track [Page 8]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 5.7 . Restrictions Appendix C contains sample C code to determine if a year is a leap year. The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe). Leap seconds cannot be predicted far into the future. The International Earth Rotation Service publishes bulletins [IERS] that announce leap seconds with a few weeks' warning. Applications should not generate timestamps involving inserted leap seconds until after the leap seconds are announced. Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion. Klyne, et. al. Standards Track [Page 9]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Appendix A . ISO 8601 Collected ABNF section 5.7 apply. ISO 8601 states that the "T" may be omitted under some circumstances. This grammar requires the "T" to avoid ambiguity. ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 gives examples where the decimal fractions are not preceded by a "0". This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is in error. date-century = 2DIGIT ; 00-99 date-decade = DIGIT ; 0-9 date-subdecade = DIGIT ; 0-9 date-year = date-decade date-subdecade date-fullyear = date-century date-year date-month = 2DIGIT ; 01-12 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year date-yday = 3DIGIT ; 001-365, 001-366 based on year date-week = 2DIGIT ; 01-52, 01-53 based on year datepart-fullyear = [date-century] date-year ["-"] datepart-ptyear = "-" [date-subdecade ["-"]] datepart-wkyear = datepart-ptyear / datepart-fullyear dateopt-century = "-" / date-century dateopt-fullyear = "-" / datepart-fullyear dateopt-year = "-" / (date-year ["-"]) dateopt-month = "-" / (date-month ["-"]) dateopt-week = "-" / (date-week ["-"]) Klyne, et. al. Standards Track [Page 12]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Klyne, et. al. Standards Track [Page 13]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Appendix D . Leap Seconds http://tycho.usno.navy.mil/leapsec.html>. In particular, it notes that: The decision to introduce a leap second in UTC is the responsibility of the International Earth Rotation Service (IERS). According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. When required, insertion of a leap second occurs as an extra second at the end of a day in UTC, represented by a timestamp of the form YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all time zones, so that time zone relationships are not affected. See section 5.8 for some examples of leap second times. The following table is an excerpt from the table maintained by the United States Naval Observatory. The source data is located at: <ftp://maia.usno.navy.mil/ser7/tai-utc.dat> Klyne, et. al. Standards Track [Page 15]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Klyne, et. al. Standards Track [Page 16]

RFC 3339 Date and Time on the Internet: Timestamps July 2002 Klyne, et. al. Standards Track [Page 17]

RFC 3339 Date and Time on the Internet: Timestamps July 2002