Aside from Tim making very good points, ISO-8601 is not a good standard - it tries to specify too many formats and ends up being so flexible that full compliance is rare. RFC 3339 is an open standard and is much simpler and more practical.
I do think ISO 8601:2004, which is now ISO 8601-1:2019, is a reasonable standard. It never tried to become a computer data type and/or format standard; it is a simple extension to human-readable date and time format modulo ambiguity. Even infrequent formats like intervals are not complex and can be easily learned. By comparison RFC 3339 only covers a very specific use case (which is the internet protocol), and if we had only RFC 3339 but not ISO 8601 we will still be fighting over mdy vs. dmy vs. ymd order for human-readable dates. The only problem with ISO 8601 is, well, it is not openly available and Tim is very right about that.
ISO 8601-2:2019 [1] is however a complete mess. It is too complex for human consumption and too ambiguous for computing uses. I argue that it should be shelved as soon as possible.
It introduces things like "?2015-?02-31" (year and month are uncertain, day is known), which may be abbreviated as "2015-02?-31". 'The character '?' (question mark) is used to mean "uncertain". The character '~' (tilde) is used to mean "approximate". The character '%’ (percent) is used to mean “both uncertain and approximate".'
There's also "1950S2" (2 significant digits, so a year between 1900 and 1999, estimated as 1950). You could also write 19XX, though that has a slightly different meaning (leaving the last two digits unspecified).
There are special "month" values to denote other divisions of a year. "2001-21" is spring of 2001, 2001-22 is summer, 2001-33 is the first quarter.
"R/20150104T083000/PM15S00/FREQ=YR;INTR=2;BYMO=1;BYDA=SU;BYHO=8,9;BYMIN=30" is a fifteen minute time interval every Sunday in January at 8:30:00 AM and 9:30:00 AM, every other year
It was created by the Library of Congress for bibliographic purposes, hence approximate and uncertain dates. I agree that they have their uses. However it is also apparent that 8601-2 is trying to amend 8601-1 to fill the gap, in my opinion very badly:
- Sub-year groupings are not very well defined and you may want to avoid them, but if you want the basic approximate and uncertain dates you can't avoid them because they all belong to the level 1. Ideally each extension to 8601-1 should have been defined separately; they do have to be described altogether to avoid the conflict among them, but any part of the additional standard should have been optional.
- 8601-2 essentially took the whole recurring time interval mechanism from iCalendar and it is a simple textual format. Why not the same for extended date and time instead of sigils (e.g. `2021-03-09;SIG=P1M`)? Unlike 8601-1 it doesn't have an absolute requirement for usability. I can only guess but editors seem to have forgotten to harmonize different specifications.
Excluding the final monstrosity of an example in the GP post here — I think some of these would actually be useful in genealogical (family tree) research software — given the correct kind of UI.
Approximate dates, and unknown portions of dates are fairly commonplace in genealogy.
(No idea what the original author was thinking though — I wonder if the intended use cases are documented anywhere?)
You're not wrong, but unfortunately a lot of libraries call it ISO 8601, and not RFC 3339. I think a lot of people probably mean RFC 3339 when they say ISO 8601 (myself included for a long time).
