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 <b...@proulx.com> > Sent: Monday, January 10, 2022 2:11 PM > To: Darryl Okahata <darryl_okah...@keysight.com> > Cc: 53...@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 >
