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"
}
Testing:
wooledg:~$ lastday 2016-03-01
2016-03-31
wooledg:~$ lastday 2016-02-01
2016-02-29
wooledg:~$ lastday 2016-01-01
2016-01-31
wooledg:~$ lastday 2000-02-01
2000-02-29
wooledg:~$ lastday 2001-02-01
2001-02-28
wooledg:~$ lastday 2100-02-01
2100-02-28
wooledg:~$ lastday 2100-03-01
2100-03-31
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
bash).
Reply to: