5. Date and Time format
This section discusses desirable qualities of date and time formats and defines a profile of ISO 8601 for use on the Internet.
5.1. Ordering
If date and time components are ordered from least precise to most precise, 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 date and time strings can be sorted as strings (e.g., using the strcmp() function in C) and will produce a time-ordered sequence. The presence of optional punctuation would violate this characteristic.
Example:
Correct ordering (year-month-day hour:minute:second):
2002-01-15T10:00:00Z
2002-07-20T15:30:00Z
2002-12-31T23:59:59Z
Incorrect format (month/day/year) cannot be sorted correctly:
01/15/2002 10:00:00
12/31/2002 23:59:59 ← String sorting puts this before July
07/20/2002 15:30:00
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.
Problem Examples:
❌ "10/11/1996" is completely unsuitable for global exchange
US: October 11, 1996
Europe: November 10, 1996
❌ Translating month abbreviations
English: "Jan", "Feb", "Mar"
French: "Jan", "Fév", "Mar" ← Breaks 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.
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 unusual precision requirements.
5.4. Redundant Information
If a date/time format includes redundant information, it introduces the possibility that the redundant information may 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 the week from the date (see Appendix B), the day of week should not be included in a date/time format.
Problem Example:
❌ "Monday, 2002-07-16T10:00:00Z"
Problem: July 16, 2002 is actually Tuesday, not Monday
If day and date don't match, which should be trusted?
✅ "2002-07-16T10:00:00Z"
Solution: Omit day of week, calculate when needed
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 syntax of 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 consistent subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory.
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].
ABNF Syntax Definition
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
Important Notes
Case Sensitivity: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively.
Specifications that use this format in environments where case is significant (such as XML) 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 uppercase letters.
Delimiters: 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 (for example) a space character.
Format Examples
Standard format:
2002-07-15T10:30:00Z
2002-07-15T10:30:00.123Z
2002-07-15T10:30:00+08:00
2002-07-15T10:30:00-04:00
With fractional seconds:
2002-07-15T10:30:00.123456Z
2002-07-15T10:30:00.52Z
Readable variants (non-standard but allowed):
2002-07-15 10:30:00Z
2002-07-15t10:30:00z
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:
| Month Number | Month/Year | Maximum 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 |
Leap Seconds
The grammar element time-second MAY have the value "60" at the end of months in which a leap second occurs. Leap seconds are used to keep UTC close to the Earth's rotational time. See Appendix D for more information about leap seconds.
Leap Second Examples:
1990-12-31T23:59:60Z ✅ Valid (leap second occurred on Dec 31, 1990)
1990-12-31T23:59:61Z ❌ Invalid (maximum is 60)
1990-06-15T23:59:60Z ❌ Invalid (leap seconds only at month end)
5.8. Examples
Here are some examples of valid RFC 3339 date-time stamps:
1985-04-12T23:20:50.52Z
Represents: April 12, 1985, 23:20:50.52 UTC
1996-12-19T16:39:57-08:00
Represents: December 19, 1996, 16:39:57 Pacific Standard Time (PST)
Equivalent UTC: 1996-12-20T00:39:57Z
1990-12-31T23:59:60Z
Represents: Leap second on December 31, 1990
1990-12-31T15:59:60-08:00
Represents: Leap second on December 31, 1990 in PST
Equivalent UTC: 1990-12-31T23:59:60Z
1937-01-01T12:00:27.87+00:20
Represents: January 1, 1937, 12:00:27.87, UTC+00:20
(Historical time zone example)
Invalid Examples
❌ 1985-04-12 (missing time)
❌ 23:20:50.52Z (missing date)
❌ 1985-04-12 23:20:50.52Z (should use 'T' not space, though some implementations allow)
❌ 1985-04-32T23:20:50.52Z (invalid date: April has no 32nd day)
❌ 1985-02-29T23:20:50.52Z (invalid date: 1985 is not a leap year)
Implementation Recommendation: Always generate the standard format (using 'T' delimiter and uppercase 'Z'), but parse liberally (accept 't', 'z', and possibly space delimiters).