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