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

[Paul Vint]

Just a quick comment as a lurker on the list: This was a very interesting
discussion, and it's discussions like these that I like following the list
for. Learned a few little things here.

Side note: Where I live in Canada, if someone refers to "next Saturday" in
conversation, one never knows if they mean (to use the `date` syntax)
"first saturday" or "second saturday". I avoid the phrase whenever possible.

Paul

On Mon, Jan 10, 2022 at 5:34 PM Darryl Okahata via GNU coreutils Bug
Reports <bug-coreutils@gnu.org> wrote:

> 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
>