Was looking for this. Yes. Whenever possible, dates should be specified in a format that is BOTH RFC 3339 and ISO 8601. I’d say both have their quirks, but the intersection of the grammars is machine-parseable and human-readable without (much) legacy baggage or (much) experimental / reserved-for-future-use noise.
Though the way it specifies raw UTC times is odd (8601 uses Z, 3339 uses -00:00), that got changed with RFC 9557 to align with 8601.
It also supports “zoned date times”, where instead of just using the UTC offset, you can also include a timezone identifier, e.g. 2020-01-01T00:00+01:00[Europe/Paris]. Useful if you’re doing calculations on dates but can be ignored otherwise.
RFC 3339 FTW!
Open source, and no ambiguous options grandfathered in.
Was looking for this. Yes. Whenever possible, dates should be specified in a format that is BOTH RFC 3339 and ISO 8601. I’d say both have their quirks, but the intersection of the grammars is machine-parseable and human-readable without (much) legacy baggage or (much) experimental / reserved-for-future-use noise.
Though the way it specifies raw UTC times is odd (8601 uses
Z, 3339 uses-00:00), that got changed with RFC 9557 to align with 8601.It also supports “zoned date times”, where instead of just using the UTC offset, you can also include a timezone identifier, e.g.
2020-01-01T00:00+01:00[Europe/Paris]. Useful if you’re doing calculations on dates but can be ignored otherwise.