How I Lost $100 and Blamed It On cal(1) | Hacker News Reader

How I Lost $100 and Blamed It On cal(1)

acg.github.com

19 pointssigil14 comments

The year calendar even showed the year as just '8', which is a dead giveaway.

But that wouldn't be visible in a standard 80x24 terminal, and since the month of November would be visible, there would be no reason to scroll up and check. He probably saw something more like this: http://pastie.org/1702013

That's exactly what happened. Still -- should have RTFM'ed.

(a) Do you really think people only use 80x24 terminals today?

(b) If the OP used an 80x24 terminal, then less(1) is his friend.

Yes, small terminals are restrictive, but those who use them nowadays should also understand unix.

Sounds like he won't make that mistake again. This is as good an example of why people should RTFM as any.

I'm sympathetic to the notion that cal(1) behaved counterintuitively, but at the same time, there's no obvious right answer here. Different people have different ideas of what is obvious. I think '08' is obviously an octal number, but that notion isn't necessarily shared by everyone.

The take-away here is to read the docs, run the program, ensure the output is what you expect, then move on.

(And, I should mention, hopefully my notion that '08' is octal isn't shared by that many people, since '8' can't be part of an octal number...)

More accurately, how not reading the manpage and not looking closely at the results cost him $100.

software should do what users expect it to do, not what developers think it should do.

And how would you suggest printing the calendar for the year 8?

Maybe the 0 in 08 could be the clue. But that's not really much better.

  GIT [team]  git stats
  git: 'stats' is not a git command. See 'git --help'.

  Did you mean this?
          status

  $ cal 08
  cal: '08' is ambiguous.

  Did you mean this?
          2008
          8AD

Date/time math is such a PITA. Honestly, I wish everyone would just switch to GMT, use 24-hour time, and write dates and times from most significant to least significant (ie, right now is 2011-03-23 02:30).

This is annoying for even technically advanced people - for example, set your phone to sync with the current timezone, then enter an event - it'll get added in your current timezone.

Lets say you get a call from home when you're in a different timezone for a meeting - you enter the appointment and when you get home it's off by a few hours.

Nobody realizes this as they're used to entering things on paper still, until it bites them.

Don't even get me started on Daylight Savings Time...

There's a great quote in the coreutils documentation[1] to this effect:

"Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time. ...

"It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion."

— Robert Grudin, Time and the Art of Living.

[1] http://www.gnu.org/software/coreutils/manual/html_node/Date-...

Worse I did `cal 9 1752` and lost two weeks

Reply on news.ycombinator.com