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

[Darryl Okahata]

Hmmm, it might be that I'm misunderstanding the syntax.  I'm used to specifying 
dates for repeating calendar events, and, to me, "first Saturday" means the 
"first Saturday of the month", and not the next Saturday from now.

  -- Darryl

-----Original Message-----
From: Bob Proulx <bob@proulx.com> 
Sent: Monday, January 10, 2022 2:11 PM
To: Darryl Okahata <darryl_okahata@keysight.com>
Cc: 53033@debbugs.gnu.org
Subject: Re: bug#53033: date has multiple "first saturday"s?

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