10 ms·

Just don't try to use two digit format for years: ~ $ cal 5 16 May 16 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9

• wtetzner 10y ago
  Well, it's displaying the calendar for May of the year 16, not the year 2016. I guess it could require you to enter 0016, but I think the given behavior is reasonable.
  • jlas 10y ago
    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.
  • vvanders 10y ago
    $5 that says you can't find anyone in IxD that would see that as reasonable.
    • zxcvcxz 10y ago
      Well it doesn't matter, they're wrong.
    • noja 10y ago
      I agree with you, but cal could be formatting the date as %04d to make it clearer.
• sigil 10y ago
  I lost a hundred bucks to this behavior. http://alangrow.com/blog/how-i-lost-100-and-blamed-cal http://alangrow.com/blog/how-i-lost-100-and-blamed-cal
  • codezero 10y ago
    How did you not notice calendar on the flight booking site? I've never used one that took a date string without showing a clickable calendar.
    • sigil 10y ago
      This was aa.com circa 2008, back when datepicker widgets were the hot new thing and calendars in popup windows ruled the earth. Call me old-fashioned but I like keyboards (still)?
      • codezero 10y ago
        archive.org shows a date picker going back as far as 2002, but it is easy to pick a date from the drop down.
        • sigil 10y ago
          The dropdown doesn't help you with "fourth Thursday in November" though, and the calendar button launches a popup window that doesn't work. On archive.org at least -- may have worked at the time, but I disable popups, so... Pretty sure my thought process was: need a Thanksgiving flight -> when is Thanksgiving this year? -> run cal(1) -> let's book.
  • ams6110 10y ago
    If you need a month in the current year, or the entire current year, that's easy: $ cal may May 2016 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 $ cal -y 2016 January February March Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 1 2 1 2 3 4 5 6 1 2 3 4 5 3 4 5 6 7 8 9 7 8 9 10 11 12 13 6 7 8 9 10 11 12 10 11 12 13 14 15 16 14 15 16 17 18 19 20 13 14 15 16 17 18 19 17 18 19 20 21 22 23 21 22 23 24 25 26 27 20 21 22 23 24 25 26 24 25 26 27 28 29 30 28 29 27 28 29 30 31 31 [...]
• dawidloubser 10y ago
  ...said nobody before the Y2K bug...