62

I'm wondering if the following date is ISO8601 compliant :

2012-03-02 14:57:05.456+0500

(for sure, 2012-03-02T14:57:05.456+0500 is compliant, but not that much human readable !) IOW, is the T between date and time mandatory ?

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
SCO
  • 1,832
  • 1
  • 24
  • 45
  • 2
    The ISO standard is absurd from a human readability point of view. An underscore (low dash), `_`, would be much better than a `T`: 2012-03-02_14:57:05.456+0500 – Rodolfo Dec 15 '19 at 21:03
  • The 2019 edition of the ISO-8601 standard made the **`T`** mandatory. I've updated my answer. – Keith Thompson Aug 07 '22 at 22:35
  • 1
    @Rodolfo The ISO 8601 standard is primarily for exchanging data-time values, not presentation to human users. You should be localizing for presentation. The title of the ISO 8601 spec includes: *Representations for information interchange*. – Basil Bourque Aug 25 '22 at 02:33

2 Answers2

54

It's required unless the "partners in information interchange" agree to omit it.

Quoting an earlier version of the ISO 8601 standard, section 4.3.2:

The character [T] shall be used as time designator to indicate the start of the representation of the time of day component in these expressions. [...]

NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard.

Omitting it is fairly common, but leaving it in is advisable if the representation is meant to be machine-readable and you don't have a clear agreement that you can omit it.

But according to Wikipedia:

In ISO 8601:2004 it was permitted to omit the "T" character by mutual agreement as in "200704051430", but this provision was removed in ISO 8601-1:2019. Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.

UPDATE : Mark Amery's comment makes a good point, that permission to omit the [T] does not necessarily imply permission to replace it with a space. So this:

2012-03-02T14:57:05.456+0500

is clearly compliant, and this:

2012-03-0214:57:05.456+0500

was permitted by earlier versions of the standard if the partners agreed to omit the T, but this:

2012-03-02 14:57:05.456+0500

apparently is not (though it's much more readable than the version with the T simply omitted).

Personally, if ISO 8601 compliance were required, I'd include the T, and if it weren't then I'd use a space (or a hyphen if it's going to be part of a file name). See also RFC 3339 section 5.6, mentioned in Charles Burns's answer.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
24

That date is not ISO-8601 compliant as Keith Thompson indicated, but it is compliant with RFC 3339, a profile of ISO 8601. Sort of. See NOTE at the bottom of the following text from RFC 3339:

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.
Community
  • 1
  • 1
Charles Burns
  • 10,310
  • 7
  • 64
  • 81
  • 5
    The fact that RFC 3339 allows this is pretty absurd; it seems like the intent of RFC 3339's authors was to create a strictly *stricter* standard than ISO 8601 while ensuring that all RFC 3339 datetimes would still conform to ISO 8601's grammar... but then they randomly decided to torpedo that objective by making the RFC 3339 grammar more permissive than ISO 8601's in this one tiny, pointless way. I don't get it; to me it's such an obviously stupid decision that I can't comprehend how it was made. But it was, whether I like it or not, and so this answer is unfortunately correct. – Mark Amery Jul 03 '18 at 10:27
  • 5
    I don't think the NOTE is relaxing the grammar of a date-time, but rather pointing out that protocols don't need to use date-time if they'd prefer to use full-date and full-time separately. For example, instead of defining something like `timestamp_header ::= "Timestamp:" date-time`, a protocol could choose to define it like `timestamp_header ::= "Timestamp:" full-date " " full-time`. – Adam M. Costello Jan 15 '19 at 03:44