bug#53033: date has multiple "first saturday"s?

[Bob Proulx]

Darryl Okahata wrote:
> Bob Proulx wrote:
>     Inconsistencies like this are why I wish it had never been implemented.  
> Best to avoid the syntax completely.
> 
> Thanks.  I'll avoid date and use either python or ruby to get this info.

To be clear what I meant was that I would avoid the ordinal word
descripts such as first, second, and third because as documented the
use of second is already used for the time unit.  I meant that instead
it would be better to use the actual numbers 1, 2, and 3, to avoid
that problem.

However reading your report again I now question whether I understand
what you were trying to report specifically.  Initially you wrote:

    $ date -d "first saturday"
    Sat Jan  8 00:00:00 PST 2022

Running it again today I get.

    $ date -d "first saturday"
    Sat Jan 15 12:00:00 AM MST 2022

    $ date -d "next saturday"
    Sat Jan 15 12:00:00 AM MST 2022

That's the first Saturday after now.  The debug is valuable
information.

    $ date --debug -d 'first saturday'
    date: parsed day part: next/first Sat (day ordinal=1 number=6)
    date: input timezone: system default
    date: warning: using midnight as starting time: 00:00:00
    date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-15 00:00:00'
    date: starting date/time: '(Y-M-D) 2022-01-15 00:00:00'
    date: '(Y-M-D) 2022-01-15 00:00:00' = 1642230000 epoch-seconds
    date: timezone: system default
    date: final: 1642230000.000000000 (epoch-seconds)
    date: final: (Y-M-D) 2022-01-15 07:00:00 (UTC)
    date: final: (Y-M-D) 2022-01-15 00:00:00 (UTC-07)
    Sat Jan 15 12:00:00 AM MST 2022

Is it useful to know the date, say..., three Saturdays from now?  I am
sure there is a good case for it.  But it always leaves me scratching
my head wondering.  Because it is basically working with the date of
today, at midnight, then the next Saturday.

    $ date --debug -d 'third saturday'
    date: parsed day part: third Sat (day ordinal=3 number=6)
    date: input timezone: system default
    date: warning: using midnight as starting time: 00:00:00
    date: new start date: 'third Sat' is '(Y-M-D) 2022-01-29 00:00:00'
    date: starting date/time: '(Y-M-D) 2022-01-29 00:00:00'
    date: '(Y-M-D) 2022-01-29 00:00:00' = 1643439600 epoch-seconds
    date: timezone: system default
    date: final: 1643439600.000000000 (epoch-seconds)
    date: final: (Y-M-D) 2022-01-29 07:00:00 (UTC)
    date: final: (Y-M-D) 2022-01-29 00:00:00 (UTC-07)
    Sat Jan 29 12:00:00 AM MST 2022

It seems to me that it would be just as clear to use numbers in that
position so as to avoid ambiguity.

    $ date --debug -d '2 saturday'
    date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
    date: input timezone: system default
    date: warning: using midnight as starting time: 00:00:00
    date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
    date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
    date: '(Y-M-D) 2022-01-22 00:00:00' = 1642834800 epoch-seconds
    date: timezone: system default
    date: final: 1642834800.000000000 (epoch-seconds)
    date: final: (Y-M-D) 2022-01-22 07:00:00 (UTC)
    date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-07)
    Sat Jan 22 12:00:00 AM MST 2022

There is no need for "second" in the "second saturday" when using the
relative time "2 saturday" produces the desired answer.

My wondering now is if "2 saturday" was actually what was desired at
all.  Perhaps it was really wanted to know the date of the first
Saturday of the month?  That's entirely a different problem.

Also, when working with dates I strongly encourage working with UTC.
I went along with the original example.  But I feel I should have been
producing examples like this instead with -uR.

    $ date -uR --debug -d '2 saturday'
    date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
    date: input timezone: TZ="UTC0" environment value or -u
    date: warning: using midnight as starting time: 00:00:00
    date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
    date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
    date: '(Y-M-D) 2022-01-22 00:00:00' = 1642809600 epoch-seconds
    date: timezone: Universal Time
    date: final: 1642809600.000000000 (epoch-seconds)
    date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC)
    date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC+00)
    Sat, 22 Jan 2022 00:00:00 +0000

Bob