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