summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3339.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3339.txt')
-rw-r--r--doc/rfc/rfc3339.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3339.txt b/doc/rfc/rfc3339.txt
new file mode 100644
index 0000000..c4c9c70
--- /dev/null
+++ b/doc/rfc/rfc3339.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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
+
+ Date and time formats cause a lot of confusion and interoperability
+ problems on the Internet. This document addresses many of the
+ problems encountered and makes recommendations to improve consistency
+ and interoperability when representing and using date and time in
+ Internet protocols.
+
+ This document includes an Internet profile of the ISO 8601 [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
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in 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
+
+
+ For more information about time scales, see Appendix E of [NTP],
+ Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-
+ TF].
+
+3. Two Digit Years
+
+ The following requirements are to address the problems of ambiguity
+ of 2-digit years:
+
+ o Internet Protocols MUST generate four digit years in dates.
+
+ o The use of 2-digit years is deprecated. If a 2-digit year is
+ received, it should be accepted ONLY if an incorrect
+ interpretation will not cause a protocol or processing failure
+ (e.g. if used only for logging or tracing purposes).
+
+ o It is possible that a program using two digit years will
+ represent years after 1999 as three digits. This occurs if the
+ program simply subtracts 1900 from the year and doesn't check
+ the number of digits. Programs wishing to robustly deal with
+ dates generated by such broken software may add 1900 to three
+ digit years.
+
+ o It is possible that a program using two digit years will
+ represent years after 1999 as ":0", ":1", ... ":9", ";0", ...
+ This occurs if the program simply subtracts 1900 from the year
+ and adds the decade to the US-ASCII character zero. Programs
+ wishing to robustly deal with dates generated by such broken
+ software should detect non-numeric decades and interpret
+ appropriately.
+
+ The problems with two digit years amply demonstrate why all dates and
+ times used in Internet protocols MUST be fully qualified.
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+ Because the daylight saving rules for local time zones are so
+ convoluted and can change based on local law at unpredictable times,
+ true interoperability is best achieved by using Coordinated Universal
+ Time (UTC). This specification does not cater to local time zone
+ rules.
+
+
+
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 4]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+4.2. Local Offsets
+
+ The offset between local time and UTC is often useful information.
+ For example, in electronic mail (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
+
+ If the time in UTC is known, but the offset to local time is unknown,
+ this can be represented with an offset of "-00:00". This differs
+ semantically from an offset of "Z" or "+00:00", which imply that UTC
+ is the preferred reference point for the specified time. RFC2822
+ [IMAIL-UPDATE] describes a similar convention for email.
+
+4.4. Unqualified Local Time
+
+ A number of devices currently connected to the Internet run their
+ internal clocks in local time and are unaware of UTC. While the
+ Internet does have a tradition of accepting reality when creating
+ specifications, this should not be done at the expense of
+ interoperability. Since interpretation of an unqualified local time
+ zone will fail in approximately 23/24 of the globe, the
+ interoperability problems of unqualified local time are deemed
+ unacceptable for the Internet. Systems that are configured with a
+ local time, are unaware of the corresponding UTC offset, and depend
+ on time synchronization with other Internet systems, MUST use a
+ mechanism that ensures correct synchronization with UTC. Some
+ suitable mechanisms are:
+
+ o Use Network Time Protocol [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
+
+
+ o Use another host in the same local time zone as a gateway to the
+ Internet. This host MUST correct unqualified local times that are
+ transmitted to other hosts.
+
+ o Prompt the user for the local time zone and daylight saving rule
+ settings.
+
+5. Date and Time format
+
+ This section discusses desirable qualities of date and time formats
+ and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+ If date and time components are ordered from least precise to most
+ precise, then a useful property is achieved. Assuming that the time
+ zones of the dates and times are the same (e.g., all in UTC),
+ expressed using the same string (e.g., all "Z" or all "+00:00"), and
+ all times have the same number of fractional second digits, then the
+ date and time strings may be sorted as strings (e.g., using the
+ strcmp() function in C) and a time-ordered sequence will result. The
+ presence of optional punctuation would violate this characteristic.
+
+5.2. Human Readability
+
+ Human readability has proved to be a valuable feature of Internet
+ protocols. Human readable protocols greatly reduce the costs of
+ debugging since telnet often suffices as a test client and network
+ analyzers need not be modified with knowledge of the protocol. On
+ the other hand, human readability sometimes results in
+ interoperability problems. For example, the date format "10/11/1996"
+ is completely unsuitable for global interchange because it is
+ interpreted differently in different countries. In addition, the
+ date format in [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
+
+ A format which includes rarely used options is likely to cause
+ interoperability problems. This is because rarely used options are
+ less likely to be used in alpha or beta testing, so bugs in parsing
+ are less likely to be discovered. Rarely used options should be made
+ mandatory or omitted for the sake of interoperability whenever
+ possible.
+
+ The format defined below includes only one rarely used option:
+ fractions of a second. It is expected that this will be used only by
+ applications which require strict ordering of date/time stamps or
+ which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+ If a date/time format includes redundant information, that introduces
+ the possibility that the redundant information will not correlate.
+ For example, including the day of the week in a date/time format
+ introduces the possibility that the day of week is incorrect but the
+ date is correct, or vice versa. Since it is not difficult to compute
+ the day of week from a date (see Appendix B), the day of week should
+ not be included in a date/time format.
+
+5.5. Simplicity
+
+ The complete set of date and time formats specified in ISO 8601
+ [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
+
+ The following profile of ISO 8601 [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
+
+ The grammar element date-mday represents the day number within the
+ current month. The maximum value varies based on the month and year
+ as follows:
+
+ Month Number Month/Year Maximum value of date-mday
+ ------------ ---------- --------------------------
+ 01 January 31
+ 02 February, normal 28
+ 02 February, leap year 29
+ 03 March 31
+ 04 April 30
+ 05 May 31
+ 06 June 30
+ 07 July 31
+ 08 August 31
+ 09 September 30
+ 10 October 31
+ 11 November 30
+ 12 December 31
+
+ 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
+
+
+5.8. Examples
+
+ Here are some examples of Internet date/time format.
+
+ 1985-04-12T23:20:50.52Z
+
+ This represents 20 minutes and 50.52 seconds after the 23rd hour of
+ April 12th, 1985 in UTC.
+
+ 1996-12-19T16:39:57-08:00
+
+ This represents 39 minutes and 57 seconds after the 16th hour of
+ December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+ Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z
+ in UTC.
+
+ 1990-12-31T23:59:60Z
+
+ This represents the leap second inserted at the end of 1990.
+
+ 1990-12-31T15:59:60-08:00
+
+ This represents the same leap second in Pacific Standard Time, 8
+ hours behind UTC.
+
+ 1937-01-01T12:00:27.87+00:20
+
+ This represents the same instant of time as noon, January 1, 1937,
+ Netherlands time. Standard time in the Netherlands was exactly 19
+ minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
+ 1937-06-30. This time zone cannot be represented exactly using the
+ HH:MM format, and this timestamp uses the closest representable UTC
+ offset.
+
+6. References
+
+ [ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
+ 9, Nov 1886.
+
+ [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet
+ Text Messages", STD 11, RFC 822, August 1982.
+
+ [IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
+ April 2001.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+
+Klyne, et. al. Standards Track [Page 10]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+ [ISO8601] "Data elements and interchange formats -- Information
+ interchange -- Representation of dates and times", ISO
+ 8601:1988(E), International Organization for
+ Standardization, June, 1988.
+
+ [ISO8601:2000] "Data elements and interchange formats -- Information
+ interchange -- Representation of dates and times", ISO
+ 8601:2000, International Organization for
+ Standardization, December, 2000.
+
+ [HOST-REQ] Braden, R., "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October
+ 1989.
+
+ [IERS] International Earth Rotation Service Bulletins,
+ <http://hpiers.obspm.fr/eop-
+ pc/products/bulletins.html>.
+
+ [NTP] Mills, D, "Network Time Protocol (Version 3)
+ Specification, Implementation and Analysis", RFC 1305,
+ March 1992.
+
+ [ITU-R-TF] International Telecommunication Union Recommendations
+ for Time Signals and Frequency Standards Emissions.
+ <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+ [RFC2119] Bradner, S, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7. Security Considerations
+
+ Since the local time zone of a site may be useful for determining a
+ time when systems are less likely to be monitored and might be more
+ susceptible to a security probe, some sites may wish to emit times in
+ UTC only. Others might consider this to be loss of useful
+ functionality at the hands of paranoia.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 11]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+ This information is based on the 1988 version of ISO 8601. There may
+ be some changes in the 2000 revision.
+
+ ISO 8601 does not specify a formal grammar for the date and time
+ formats it defines. The following is an attempt to create a formal
+ grammar from ISO 8601. This is informational only and may contain
+ errors. ISO 8601 remains the authoritative reference.
+
+ Note that due to ambiguities in ISO 8601, some interpretations had to
+ be made. First, ISO 8601 is not clear if mixtures of basic and
+ extended format are permissible. This grammar permits mixtures. ISO
+ 8601 is not clear on whether an hour of 24 is permissible only if
+ minutes and seconds are 0. This assumes that an hour of 24 is
+ permissible in any context. Restrictions on date-mday in 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
+
+
+ datespec-full = datepart-fullyear date-month ["-"] date-mday
+ datespec-year = date-century / dateopt-century date-year
+ datespec-month = "-" dateopt-year date-month [["-"] date-mday]
+ datespec-mday = "--" dateopt-month date-mday
+ datespec-week = datepart-wkyear "W"
+ (date-week / dateopt-week date-wday)
+ datespec-wday = "---" date-wday
+ datespec-yday = dateopt-fullyear date-yday
+
+ date = datespec-full / datespec-year
+ / datespec-month /
+ datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+Time:
+
+ time-hour = 2DIGIT ; 00-24
+ time-minute = 2DIGIT ; 00-59
+ time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
+ ; leap-second rules
+ time-fraction = ("," / ".") 1*DIGIT
+ time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
+ time-zone = "Z" / time-numoffset
+
+ timeopt-hour = "-" / (time-hour [":"])
+ timeopt-minute = "-" / (time-minute [":"])
+
+ timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
+ timespec-minute = timeopt-hour time-minute [[":"] time-second]
+ timespec-second = "-" timeopt-minute time-second
+ timespec-base = timespec-hour / timespec-minute / timespec-second
+
+ time = timespec-base [time-fraction] [time-zone]
+
+ iso-date-time = date "T" time
+
+Durations:
+
+ dur-second = 1*DIGIT "S"
+ dur-minute = 1*DIGIT "M" [dur-second]
+ dur-hour = 1*DIGIT "H" [dur-minute]
+ dur-time = "T" (dur-hour / dur-minute / dur-second)
+ dur-day = 1*DIGIT "D"
+ dur-week = 1*DIGIT "W"
+ dur-month = 1*DIGIT "M" [dur-day]
+ dur-year = 1*DIGIT "Y" [dur-month]
+ dur-date = (dur-day / dur-month / dur-year) [dur-time]
+
+ duration = "P" (dur-date / dur-time / dur-week)
+
+
+
+Klyne, et. al. Standards Track [Page 13]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+Periods:
+
+ period-explicit = iso-date-time "/" iso-date-time
+ period-start = iso-date-time "/" duration
+ period-end = duration "/" iso-date-time
+
+ period = period-explicit / period-start / period-end
+
+Appendix B. Day of the Week
+
+ The following is a sample C subroutine loosely based on Zeller's
+ Congruence [Zeller] which may be used to obtain the day of the week
+ for dates on or after 0000-03-01:
+
+ char *day_of_week(int day, int month, int year)
+ {
+ int cent;
+ char *dayofweek[] = {
+ "Sunday", "Monday", "Tuesday", "Wednesday",
+ "Thursday", "Friday", "Saturday"
+ };
+
+ /* adjust months so February is the last one */
+ month -= 2;
+ if (month < 1) {
+ month += 12;
+ --year;
+ }
+ /* split by century */
+ cent = year / 100;
+ year %= 100;
+ return (dayofweek[((26 * month - 2) / 10 + day + year
+ + year / 4 + cent / 4 + 5 * cent) % 7]);
+ }
+
+Appendix C. Leap Years
+
+ Here is a sample C subroutine to calculate if a year is a leap year:
+
+ /* This returns non-zero if year is a leap year. Must use 4 digit
+ year.
+ */
+ int leap_year(int year)
+ {
+ return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+ }
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 14]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+Appendix D. Leap Seconds
+
+ Information about leap seconds can be found at:
+ <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
+
+
+ This table shows the date of the leap second, and the difference
+ between the time standard TAI (which isn't adjusted by leap seconds)
+ and UTC after that leap second.
+
+ UTC Date TAI - UTC After Leap Second
+ -------- ---------------------------
+ 1972-06-30 11
+ 1972-12-31 12
+ 1973-12-31 13
+ 1974-12-31 14
+ 1975-12-31 15
+ 1976-12-31 16
+ 1977-12-31 17
+ 1978-12-31 18
+ 1979-12-31 19
+ 1981-06-30 20
+ 1982-06-30 21
+ 1983-06-30 22
+ 1985-06-30 23
+ 1987-12-31 24
+ 1989-12-31 25
+ 1990-12-31 26
+ 1992-06-30 27
+ 1993-06-30 28
+ 1994-06-30 29
+ 1995-12-31 30
+ 1997-06-30 31
+ 1998-12-31 32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 16]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+Acknowledgements
+
+ The following people provided helpful advice for an earlier
+ incarnation of this document: Ned Freed, Neal McBurnett, David
+ Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due
+ to participants of the IETF Calendaring/Scheduling working group
+ mailing list, and participants of the time zone mailing list.
+
+ The following reviewers contributed helpful suggestions for the
+ present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
+ Paul Eggert provided many careful observations regarding the
+ subtleties of leap seconds and time zone offsets. The following
+ people noted corrections and improvements to earlier drafts: Dr John
+ Stockton, Jutta Degener, Joe Abley, and Dan Wing.
+
+Authors' Addresses
+
+ Chris Newman
+ Sun Microsystems
+ 1050 Lakes Drive, Suite 250
+ West Covina, CA 91790 USA
+
+ EMail: chris.newman@sun.com
+
+
+ Graham Klyne (editor, this revision)
+ Clearswift Corporation
+ 1310 Waterside
+ Arlington Business Park
+ Theale, Reading RG7 4SA
+ UK
+
+ Phone: +44 11 8903 8903
+ Fax: +44 11 8903 9000
+ EMail: GK@ACM.ORG
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 17]
+
+RFC 3339 Date and Time on the Internet: Timestamps July 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al. Standards Track [Page 18]
+