Re: date(1): -d argument parsing error

[James Youngman]

On Wed, Dec 10, 2008 at 1:08 AM, Jan Minář <address@hidden> wrote:
> 2008/12/10 James Youngman <address@hidden>:
>> $ date -d "next `LC_ALL=C date +%A`"
>> mercredi 10 décembre 2008, 00:00:00 (UTC+0000)
>           ^^^^^^^^^^^
>
> You've just demonstrated that the bug is present in the French
> localization as well -- the you got is *today*, not *next* Wednesday,
> as it should be.

Now I see what you mean.   The effect appears to be caused by this
piece of code in gnulib's getdate.y:

      if (pc.days_seen && ! pc.dates_seen)
        {
          tm.tm_mday += ((pc.day_number - tm.tm_wday + 7) % 7
                         + 7 * (pc.day_ordinal - (0 < pc.day_ordinal)));
          tm.tm_isdst = -1;
          Start = mktime (&tm);
          if (Start == (time_t) -1)
            goto fail;
        }

Certainly on the basis of the documentation (getdate.texi lines
331-337 and 389-398), this would appear to be a bug:-

@findex next @var{day}
@findex last @var{day}
A number may precede a day of the week item to move forward
supplementary weeks.  It is best used in expression like @samp{third
monday}.  In this context, @samp{last @var{day}} or @samp{next
@var{day}} is also acceptable; they move one week before or after
the day that @var{day} by itself would represent
...

@findex now @r{in date strings}
@findex today @r{in date strings}
@findex this @r{in date strings}
The strings @samp{now} or @samp{today} are relative items corresponding
to zero-valued time displacement, these strings come from the fact
a zero-valued time displacement represents the current time when not
otherwise changed by previous items.  They may be used to stress other
items, like in @samp{12:00 today}.  The string @samp{this} also has
the meaning of a zero-valued time displacement, but is preferred in
date strings like @samp{this thursday}.


Specifically, my take on this is that "next" is clearly intended to
move the date forward, and had the user wanted a movement of zero days
when today is the indicated weekday, they had the option of specifying
'this Wednesday' instead of 'next Wednesday'.

I'm normally reluctant to accept the need to change getdate.y (though
this is not my call anyway of course, I'm not a maintainer) because of
the fact that it's been around a long time and somebody somewhere may
be relying on the current behaviour.  However, I also note that the
"next <weekday-name>" is not currently tested by gnulib's
tests/test-getdate.c program, and so it looks to me as if the weight
of evidence favours changing this.  The difficulty of course is in not
breaking something else.

I've added address@hidden to the CC list.   That's the place to
send your patch to fix the bug.  The gnulib README file describes how
to contribute.   For other information about gnulib, including
directions for accessing the GIT source repository, please see
http://savannah.gnu.org/projects/gnulib.

Thanks,
James.