Web lists-archives.com

[Was: Re: policy around 'wontfix' bug tag




On 05.02.18 09:39, Greg Wooledge wrote:
> On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> > All you describe is convenience for programmatic use. As I explained,
> > this parser is meant for interactive use.
> 
> What on EARTH made you think THAT?

The fuzzy grammar of the date string makes programmatic use a bit
empirical, I must admit.

> I promise you, people ARE using date -d '...' in shell scripts.
> LOTS of people.  Hell, I've done it.(*)

A data point: I have been using "date" for a good 30 years, on hp-ux,
SunOS, Solaris, and now linux - pretty much _exclusively_ in scripts,
even with -d. An example still in use even scripts the "human readable"
input:

#!/bin/bash
[ `date '+%H'` -lt 4 ] && day="yesterday" || day="today"
d="`date -d $day '+%a %b %_d'`"
...
echo "`date -d $day '+%a %b %_d'`" $n >> ~/fetchmail_traffic

If a new formal grammar largely consistent with the "mostly free format
human readable date string" were defined in the manpage, then that could
be a step forward.

> If I'm a human working in an interactive shell, and I want to see "the
> date of the Sunday that occurred in the previous week", I will simply
> run cal(1) instead.  (Or for that specific example on this specific
> day, "cal 1 2018" or even "cal 2018".)  It's a lot easier than trying
> to guess which recipe you can put into date -d to get the same result.

Yes, cal is less effort. I use date interactively only when developing a
script. For me, the "mostly free format human readable date string" is
irrelevant, as it merely serves as an undocumented grammar.

> 
> (*) One specific shell script use case was "Get the last date of a given
> month."  Now, obviously you can just set up an array of hard-coded month
> ending dates, and then write a function to determine whether the current
> year is a leap year for the February case.  But if you want to do it with
> GNU date -d, then you have to guess a magic incantation that actually
> works.  Usually by trial and error.
> 
> Anyway, here's what I came up with:
> 
> lastday() {
>     date +%Y-%m-%d -d "$1 1 day ago + 1 month"
> }
...

> How does it work?  Who knows!

That's quite straightforward, I submit. Omitting the "+ 1 month", your
expression is equivalent to: (with $1 substituted for example 1)

$ date +%Y-%m-%d -d "2016-03-01 - 1 day"
2016-02-29

which simply steps backward from first of the month to last of the
previous. Then stepping forward a month merely avoids the need to input
first of next month for last of this one.

> But it seems to work.  It correctly
> handles the oddball corner cases like Feb 2100 (which is not a leap
> year), and the March-that-follows-a-leap-day as well as the
> March-that-does-not-follow-a-leap-day.  So that is where I left it.

And for the far past, cal is superior; compare:

$ cal -3 9 1752
    August 1752          September 1752         October 1752      
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
                   1         1  2 14 15 16   1  2  3  4  5  6  7  
 2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14  
 9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21  
16 17 18 19 20 21 22                        22 23 24 25 26 27 28  
23 24 25 26 27 28 29                        29 30 31              
30 31

with

$ date +%Y-%m-%d -d "1752-10-01 - 1 day"
date: invalid date `1752-10-01 - 1 day'

Cal delivers the goods, but date lacks the time travelling range.

Erik