datestandardsdatetime-formatiso

In an ISO 8601 date, is the T character mandatory?


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 ?


Solution

  • 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.