Because dates in calendar are closer than they appear

Starting around the year 2000, I've published a little essay called
'Recipe for a Successful Linux User Group', which has subsequently been
republished in Usenix Association's ;login magazine and elswhere.  It's
at http://linuxmafia.com/faq/Linux_PR/newlug.html , and widely linked.

For the first time in a long while, I've made a modest addition to it,
under item 12, that is about /usr/bin/cal being your friend for event
timing and planning.  I just added this bit:

  As the old joke goes, "Dates In Calendar Are Closer Than They Appear."
  _Use whatever works_ to ensure that announcements of upcoming events go
  out _on time_, which for most groups means somewhere between 1 week and 
  24 hours before show time.  Personally, I find this simple script tool 
  handy as local utility /usr/local/bin/daysutil, to do quick checks from 
  my shell prompt:

  #!/bin/sh
  echo "Type the future date in ISO 8601 (YYYY-MM-DD) format."
  read futuredate
  echo $futuredate | tr -s '-' ' ' | awk '{dt=mktime($0 " 00-00-00")-systime(); print int(dt/86400+1) " days";}' 

Now, that's a sucky little perfunctory script[1].  Among other things,
it's a bit haphazard about the definition of 'day' (but precise enough,
IMO), and I'm sure it could be a lot better (and probably ought to be in
Python or Ruby).  Also, there are probably a lot of (rare) ugly edge
cases and (rare) problems with daylight saving time transitions, such
that it would probably be better off being calculated using UTC times.

But my rule:  As with system backups, the halfassed utility script you
actually write and use beats the much better one you never get around
to, every time.

Feel welcome, nay, invited, to counter with a better more idiot-proof,
and more elegant script.  For starters, it could parse input from its
command line, and error-trap on inappropriate input formats and input
values outside of bounds.


Example usage:

I haven't checked on Kevin's planning for the January 2016 SVLUG meeting
at Cavium, but (last I heard) he was still aiming for the traditional
1st Wednesday formula, at least for that month.  So, this is the way I'd
check on those things.

Which Jan. 2017 date will the 1st Wednesday be?

$ cal Jan 2017
    January 2017    
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            
$

OK, 2017-01-04, then.  So, how far are we from there, right now?

$ daysuntil 
Type the future date in ISO 8601 (YYYY-MM-DD) format.
2017-01-04
21 days
$

So, still three weeks away, but beware, because dates sneak up on you.

I hope my trivial little script -- or the better one I've just inspired
-- helps people.


[1] It leverages the mktime function in all POSIX awk implementations.
https://www.gnu.org/software/gawk/manual/html_node/Time-Functions.html
mktime expects the space character as a delimiter, but personally I 
vastly prefer ISO 8601 format, so I use 'tr' to strip and replace the
hyphens for mktime's benefit.