5 ms·

I think better UX would be show me the closest one to today, which is 2016

• throwanem 10y ago
  It's showing you the one you asked for.
• fredley 10y ago
  For command line utilities I'll take correctness over usability any day.
  • fosco 10y ago
    Agreed, this is great engineering and design. As expected, it does exactly what you tell it to.
  • raverbashing 10y ago
    You're right, correctness is important. And also wrong by thinking usability gets in the way of correctness 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)
    • gkya 10y ago
      > Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000) 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.
      • d0mine 10y ago
        Yes, 'cal 16' is ambiguous (is it 0016, 1916, 2016? Different software may return different answers). Without an explicit flag that should be used in a script, the dwim behavior (2016) seems more appropriate for the interactive use.
        • gkya 10y ago
          cal 16 unambiguously refers to 16 a.d. Don't forget that we include an apostrophe before a shortened year.
      • raverbashing 10y ago
        > According to what? Your 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.
      • deleted 10y ago
        [deleted]
• snvzz 10y ago
  Even better UX is to show what you've requested, which is 16.
  • jlas 10y ago
    The western calendar didn't even exist until the 1500s, so asking for the calendar in 16AD is sort of contrived.
• ptaipale 10y ago
  The closest 16 to today is 16.
• jdeisenberg 10y ago
  Or, always show the year as four digits with leading zeros. Seeing "May 0016" gives you an indication that it just might not be this year.
  • jerkstate 10y ago
    That will cause problems in less than 8 thousand years.
    • qbrass 10y ago
      It will anyway. cal: year `10000' not in range 1..9999
• oneeyedpigeon 10y ago
  Surely the correct thing would be a config setting to warn you if you're displaying a year in the past (or a year before one that you specify - e.g. 100). Meh, even `cal 8` displays the year prominently at the top.
• mturmon 10y ago
  According to wikipedia, cal was in First Edition Unix, back in 1971. You can assume it's been used in scripts and it would be hard to change default behavior now, or any time in the last 30 years for that matter. 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.