453

ISO 8601 and RFC 3339 seem to be two formats that are common the web. Should I use one over the other? Is one just an extension? Do I really need to care that bad?

Community
  • 1
  • 1
  • 86
    I've changed the link to the RFC from http://www.ietf.org/rfc/rfc3339.txt to the HTML version at http://tools.ietf.org/html/rfc3339. When linking to RFCs you should *always* link to the HTML versions at http://tools.ietf.org/html. Not only are they easier to navigate thanks to section links, but, importantly, they list at the top any RFCs that have updated or obsoleted the RFC you're reading. People unwittingly cite obsolete RFCs all the time on Stack Overflow, and I'm going to keep repeating this advice until that problem goes away. (For the avoidance of doubt, *this* RFC is not obsolete.) – Mark Amery Jun 07 '15 at 21:04
  • 4
    This is a good post to explain their difference: https://ijmacd.github.io/rfc3339-iso8601/ – Fangda Han Oct 24 '21 at 15:48
  • https://ijmacd.github.io/rfc3339-iso8601/ – Ray Hulha Oct 25 '21 at 08:59

5 Answers5

347

Is one just an extension?

Pretty much, yes - RFC 3339 is listed as a profile of ISO 8601. Most notably RFC 3339 specifies a complete representation of date and time (only fractional seconds are optional). The RFC also has some small, subtle differences. For example truncated representations of years with only two digits are not allowed -- RFC 3339 requires 4-digit years, and the RFC only allows a period character to be used as the decimal point for fractional seconds. The RFC also allows the "T" to be replaced by a space (or other character), while the standard only allows it to be omitted (and only when there is agreement between all parties using the representation).

I wouldn't worry too much about the differences between the two, but on the off-chance your use case runs in to them, it'd be worth your while taking a glance at:

Mike Graf
  • 5,077
  • 4
  • 45
  • 58
ConroyP
  • 40,958
  • 16
  • 80
  • 86
  • 1
    ISO 8601 also includes some not-so-simple extensions like intervals and periodically repeating timepoints, whereas RFC 3339 only deals with timestamps. The following (taken from the WMS specification) is legal ISO but not RFC: `Daily data taken at noon since 15 April 1995 (periodic interval): 1995-04-22T12:00Z/2000-06-21T12:00Z/P1D` – geira Jun 12 '14 at 14:45
  • 29
    Sorry Java Guy, but that's not quite correct. The appendix you refer to is informational only and the restriction is for the sake of keeping the grammar simpler. The note at the end of section 5.6 clearly states that a space may be used for the sake of readability, referring to the earlier mention of readability which is the subject of section 5.2. to quote: "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." – Greg A. Woods Aug 15 '14 at 22:16
  • 10
    @JavaGuy The appendix you've linked to isn't even talking about the RFC 3339 syntax - it's titled **ISO 8601 Collected ABNF** and is an attempt to formally describe the grammar of *ISO 8601* using [ABNF](https://tools.ietf.org/html/rfc5234). Nothing it says should be taken as evidence about the RFC 3339 datetime syntax. – Mark Amery Jun 07 '15 at 21:29
  • 3
    FWIW: It has been discussed on the coreutils list: http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00019.html – Frederick Nord Sep 27 '16 at 13:53
  • 2
    "Most notably RFC 3339 requires a _complete representation_ of date and time" I'm not sure what this means. RFC 3339 explicitly allows ISO 8601 constructs like "YYYY", "YYYY-MM", "--MM-DD", etc. The grammar is `date = datespec-full / datespec-year / datespec-month / datespec-mday / datespec-week / datespec-wday / datespec-yday`. – Matthew Ratzloff Apr 05 '18 at 21:06
  • 3
    "RFC 3339 requires a complete representation of date and time" - This is not correct. Please consider editing the answer. I emailed one of the RFC authors just to be completely sure. The reply includes "I think it's perfectly fair game to reference the [RFC3339] 'full-date' syntax production if you want just a date stamp. … maybe an erratum might be in order" Also, JSON Schema v7 has explicit support for RFC 3339 date-only (full-date) and time-only (full-time) profiles. https://json-schema.org/draft-07/json-schema-release-notes.html. – Justin Maxwell Feb 04 '19 at 04:48
  • 18
    I'm the author that Justin (previous comment) contacted (though not responsible for most of the heavy lifting there). I confirm his comment. Generally, I would suggest specification documents like RFC3339 *specify* rather than *require* - it's the context of use that determines what is *required*. As long as it's clear what is intended, then referencing a specific syntax production is fine. (This is not really different to what RFC3339 itself does in making selective reference to ISO8601.) See also the NOTE in [section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). – Graham Klyne Feb 04 '19 at 10:14
101

There are lots of differences between ISO 8601 and RFC 3339. Here is some examples to give you an idea:

2020-12-09T16:09:53+00:00 is a date time value that is compliant by both standards.

2020-12-09 16:09:53+00:00 uses a space to separate the date and time. This is allowed by RFC 3339 but not allowed by ISO 8601.

2020-12-09T16:09:53-00:00 specifies a negative zero in the time offset. This is allowed by RFC 3339 but not allowed by ISO 8601.

20201209T160953Z omits the hyphens and colons. This is allowed by ISO 8601 but not allowed by RFC 3339.

ISO 8601 allows for things like ordinal dates such as 2020-344 which represents the 344th day of year 2020. RFC 3339 doesn't allow for that.

For your questions:

Is one just an extension?

No. As shown above each standard supports syntax variations not supported by the the other standard. So one syntax is not a superset or an extension of the other.

Should I use one over the other?

Of course this depends on your scenario. A safe general strategy is to generate date time strings that are valid by both standards.

Another good general strategy is to use an existing standard library for parsing/formatting date time strings and not write custom implementations unless you are addressing a genuinely custom scenario.

Do I really need to care that bad?

Well, that's up to you. Most regular developers who deal with date time strings should have a high level understanding but don't need to dive into the details.

clay
  • 18,138
  • 28
  • 107
  • 192
22

RFC 3339 is mostly a profile of ISO 8601, but is actually inconsistent with it in borrowing the "-00:00" timezone specification from RFC 2822. This is described in the Wikipedia article.

Zefram
  • 221
  • 2
  • 2
6

It seems difficult and/or expensive to actually get access to the ISO spec. Which is why we see many links to the wikipedia page instead.

For this reason alone I prefer the RFC3339: you can go straight to primary source.

jojo hohanon
  • 61
  • 1
  • 1
1

You shouldn't have to care that much. RFC 3339, according to itself, is a set of standards derived from ISO 8601. There's quite a few minute differences though, and they're all outlined in RFC 3339. I could go through them all here, but you'd probably do better just reading the document for yourself in the event you're worried:

https://www.rfc-editor.org/rfc/rfc3339

Community
  • 1
  • 1
David Morton
  • 16,338
  • 3
  • 63
  • 73