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.
ISO 8601
ISO week date
👆
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.This is the only way to date.
No need for dashes
Except for, yknow, human readability
Are a lots of things gonna break in about 8000 years?
I’ve recently noticed web forms and appointment emails start to use that format. Maybe web devs are sneaking it in bit by bit.