Web lists-archives.com

Re: policy around 'wontfix' bug tag

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?

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

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.

(*) 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"


wooledg:~$ lastday 2016-03-01
wooledg:~$ lastday 2016-02-01
wooledg:~$ lastday 2016-01-01
wooledg:~$ lastday 2000-02-01
wooledg:~$ lastday 2001-02-01
wooledg:~$ lastday 2100-02-01
wooledg:~$ lastday 2100-03-01

How does it work?  Who knows!  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.

That was written a long time ago.  In newer projects, I have generally
gone with the hard-coded array + is_leap_year function (but not in