Should EDTF dates with only a year be humanised to year <year>

[mzeinstra]

Some community members argued that dates like '2023', '1800', '1924' should be humanised to 'year 2023', 'year 1800', 'year 1924', etc.

I would like to have an open community discussion on this. Are people in favor/against this? Until we have some input we will have this labeled as a question.

[JeroenDeDauw]

We actually already have humanizations of years. See 100 in

We purposefully did not humanize years such as 1984 since people already understand what you mean. The differentiation is really simple at the moment, and perhaps should also include an upper bound such as 3000.

Or perhaps we should drop the check and always show a humanization. All those options are trivial to implement.

[JeroenDeDauw]

Here is a better version of the "smart" behavior: #94

[cnralux]

I find it quite strange that almost all EDTF strings get a humanized string (= the gray text in brackets), except for positive "year only"-dates, where that space remains empty.

#94 might be a solution, but what about years like 1234 or 2222? Do users recognize them as years or as typos? Adding "year" could harmonize this for all forms of EDTF strings with "year only"-dates (including those starting with "Y").

[JeroenDeDauw]

This is actually not trivial to fix. Here are examples of changed humanization if we always humanize year. We should at least pay attention to context so that "year" does not get inserted inside of other messages where it really is not needed.

.- 'February 14th, 2021'
+'February 14th, Year 2021'

-'2019 to 2021'
+'Year 2019 to Year 2021'

-'01:02:03 UTC April 12th, 1985'
+'01:02:03 UTC April 12th, Year 1985'

-'January 1st, 1000, April 20th, 4242 or a day in between'
+'January 1st, Year 1000, April 20th, Year 4242 or a day in between'

[JeroenDeDauw]

Decision together with @mzeinstra and @digitaalwerktuig: we will not always humanize years because of the above issue with compound messages.

Potential improvement to smart behavior: #94