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 ?
Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in ISO 8601. This profile does not specify how many digits may be used to represent the decimal fraction of a second.
ISO 8601 represents date and time by starting with the year, followed by the month, the day, the hour, the minutes, seconds and milliseconds. For example, 2020-07-10 15:00:00.000, represents the 10th of July 2020 at 3 p.m. (in local time as there is no time zone offset specified—more on that below).
The T is just a literal to separate the date from the time, and the Z means “zero hour offset” also known as “Zulu time” (UTC). If your strings always have a “Z” you can use: SimpleDateFormat format = new SimpleDateFormat( “yyyy-MM-dd'T'HH:mm:ss).
Yes, it is valid. It's basically extended in terms of subsecond support, but that's allowed by the standard.
It's required unless the "partners in information interchange" agree to omit it.
Quoting 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.
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
is permitted if the partners agree 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). My guess, and it's nothing more than that, was that the intent was to allow the 'T' to be replaced by a space, but the standard doesn't say that.
See also RFC 3339 section 5.6, mentioned in Charles Burns's answer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With