Comment by wongarsu | Hacker News Reader

Comment by wongarsu | Hacker News Reader

Parent Full thread

> ISO 8601-2:2019 [1] is however a complete mess

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

Genuinely curious to hear the supposed use case for this stuff from the original author.

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?)

Refugee children are often assigned birthday Jan 1 with an estimated birth year, for purpose of filling out immigration forms. More: https://www.racgp.org.au/afpbackissues/2008/200810/200810ben...

Though, I doubt many collection systems actually recognize this format for uncertain dates.

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.

Reply on news.ycombinator.com