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.
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.
[1] https://web.archive.org/web/20171020000043/https://www.loc.g... (draft standard)
Wow, you weren't joking.
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
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?)
Though, I doubt many collection systems actually recognize this format for uncertain dates.
- 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.