Hacker News Reader

Comment by jefftk | Hacker News Reader

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
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
    31
    ~ $ cal 5 2016
          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

View on HN

I lost a hundred bucks to this behavior.

http://alangrow.com/blog/how-i-lost-100-and-blamed-cal

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.

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

archive.org shows a date picker going back as far as 2002, but it is easy to pick a date from the drop down.

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.

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

    [...]

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.

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

It's showing you the one you asked for.

For command line utilities I'll take correctness over usability any day.

Agreed, this is great engineering and design. As expected, it does exactly what you tell it to.

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)

> 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.

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.

cal 16 unambiguously refers to 16 a.d. Don't forget that we include an apostrophe before a shortened year.

> 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.

Even better UX is to show what you've requested, which is 16.

The western calendar didn't even exist until the 1500s, so asking for the calendar in 16AD is sort of contrived.

The closest 16 to today is 16.

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.

That will cause problems in less than 8 thousand years.

It will anyway.

  cal: year `10000' not in range 1..9999

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.

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.

$5 that says you can't find anyone in IxD that would see that as reasonable.

Well it doesn't matter, they're wrong.

I agree with you, but cal could be formatting the date as %04d to make it clearer.

...said nobody before the Y2K bug...

Reply on news.ycombinator.com