I think better UX would be show me the closest one to today, which is 2016
Usability helps with being correct
Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000)
'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to)
According to what? Your use?
> 'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to)
The command wants a year number as input. '16 is an ambiguous abbreviation that gains meaning only within context. As the command can't ask you what you meant, the default behaviour is sane.
Without an explicit flag that should be used in a script, the dwim behavior (2016) seems more appropriate for the interactive use.
Do you know anyone or any use case that requires calculations of years between 0-99 and uses cal?
Yes, it is quite obvious that most uses is for years > 1900, you're free to do a study yourself if that's what you want.
> As the command can't ask you what you meant, the default behaviour is sane.
Not from an usability point of view.
I've used it myself in scripts to find Julian day numbers, to count days-within-months, etc. -- for old science data -- before there were more robust ways to do this stuff.
It's hard to insert DWIM behaviors into old command-line utilities, because "what I mean" is not clear.
cal: year `10000' not in range 1..9999