GNU bug report logs - #53033
date has multiple "first saturday"s?

Previous Next

To reply to this bug, email your comments to 53033 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Darryl Okahata <darryl_okahata <at> keysight.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: date has multiple "first saturday"s?
Date: Wed, 5 Jan 2022 18:33:23 +0000

(This has been verified to occur with 9.0.)

        $ date -d "first saturday"
        Sat Jan  8 00:00:00 PST 2022

Unless there is some weird definition of "first Saturday", shouldn't this be
the 1st (New Year's Day)?

Also, I ran this last week (I think on the 29th or the 30th), and it did
properly report the 1st.  Now that it's after the 1st, it's reporting the 8th.
Side note: I'm happy that it reported Jan 1st as the "first Saturday" even
though the date was still in December, but is there a way of getting the
"first Saturday" for an arbitrary year/month?  All my attempts just get the
"invalid date" error.

  -- Darryl

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Darryl Okahata via GNU coreutils Bug Reports <bug-coreutils <at> gnu.org>
Cc: 53033 <at> debbugs.gnu.org, Darryl Okahata <darryl_okahata <at> keysight.com>
Subject: Re: bug#53033: date has multiple "first saturday"s?
Date: Wed, 05 Jan 2022 23:10:18 +0100

On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote:

>         $ date -d "first saturday"
>         Sat Jan  8 00:00:00 PST 2022
>
> Unless there is some weird definition of "first Saturday", shouldn't this be
> the 1st (New Year's Day)?

Try date --debug.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Darryl Okahata <darryl_okahata <at> keysight.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>, Darryl Okahata via GNU coreutils
 Bug Reports <bug-coreutils <at> gnu.org>
Cc: "53033 <at> debbugs.gnu.org" <53033 <at> debbugs.gnu.org>
Subject: RE: bug#53033: date has multiple "first saturday"s?
Date: Wed, 5 Jan 2022 23:14:43 +0000

From coreutils 9.0 (note the difference between the "second" and "third"
saturdays):


$ src/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-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: timezone: system default
date: final: 1641628800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan  8 00:00:00 PST 2022

$ src/date --debug -d "second saturday"
date: parsed relative part: +1 seconds
date: parsed day part: Sat (day ordinal=0 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns),
date:     new time = 1641628801 epoch-seconds
date: timezone: system default
date: final: 1641628801.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan  8 00:00:01 PST 2022

$ src/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-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' = 1642838400 epoch-seconds
date: timezone: system default
date: final: 1642838400.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 22 00:00:00 PST 2022

  -- Darryl

-----Original Message-----
From: Andreas Schwab <schwab <at> linux-m68k.org> 
Sent: Wednesday, January 5, 2022 2:10 PM
To: Darryl Okahata via GNU coreutils Bug Reports <bug-coreutils <at> gnu.org>
Cc: 53033 <at> debbugs.gnu.org; Darryl Okahata <darryl_okahata <at> keysight.com>
Subject: Re: bug#53033: date has multiple "first saturday"s?

On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote:

>         $ date -d "first saturday"
>         Sat Jan  8 00:00:00 PST 2022
>
> Unless there is some weird definition of "first Saturday", shouldn't 
> this be the 1st (New Year's Day)?

Try date --debug.

--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Message #20 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Darryl Okahata <darryl_okahata <at> keysight.com>
To: Darryl Okahata <darryl_okahata <at> keysight.com>, "schwab <at> linux-m68k.org"
 <schwab <at> linux-m68k.org>, "53033 <at> debbugs.gnu.org" <53033 <at> debbugs.gnu.org>
Subject: RE: bug#53033: date has multiple "first saturday"s?
Date: Thu, 6 Jan 2022 21:50:26 +0000

        $ src/date --debug -d "second saturday"
        date: parsed relative part: +1 seconds
        date: parsed day part: Sat (day ordinal=0 number=6)
        date: input timezone: system default
        date: warning: using midnight as starting time: 00:00:00
        date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00'
        date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
        date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
        date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns),
        date:     new time = 1641628801 epoch-seconds
        date: timezone: system default
        date: final: 1641628801.000000000 (epoch-seconds)
        date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC)
        date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08)
        src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
        Sat Jan  8 00:00:01 PST 2022

I just noticed that "second Saturday" is being parsed as "Saturday + 1 second".

  -- Darryl

-----Original Message-----
From: Bug-coreutils <bug-coreutils-bounces+darryl_okahata=keysight.com <at> gnu.org> On Behalf Of Darryl Okahata via GNU coreutils Bug Reports
Sent: Wednesday, January 5, 2022 3:15 PM
To: schwab <at> linux-m68k.org; 53033 <at> debbugs.gnu.org
Subject: bug#53033: date has multiple "first saturday"s?

From coreutils 9.0 (note the difference between the "second" and "third"
saturdays):


$ src/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-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: timezone: system default
date: final: 1641628800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan  8 00:00:00 PST 2022

$ src/date --debug -d "second saturday"
date: parsed relative part: +1 seconds
date: parsed day part: Sat (day ordinal=0 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns),
date:     new time = 1641628801 epoch-seconds
date: timezone: system default
date: final: 1641628801.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan  8 00:00:01 PST 2022

$ src/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-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' = 1642838400 epoch-seconds
date: timezone: system default
date: final: 1642838400.000000000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 22 00:00:00 PST 2022

  -- Darryl

-----Original Message-----
From: Andreas Schwab <schwab <at> linux-m68k.org>
Sent: Wednesday, January 5, 2022 2:10 PM
To: Darryl Okahata via GNU coreutils Bug Reports <bug-coreutils <at> gnu.org>
Cc: 53033 <at> debbugs.gnu.org; Darryl Okahata <darryl_okahata <at> keysight.com>
Subject: Re: bug#53033: date has multiple "first saturday"s?

On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote:

>         $ date -d "first saturday"
>         Sat Jan  8 00:00:00 PST 2022
>
> Unless there is some weird definition of "first Saturday", shouldn't
> this be the 1st (New Year's Day)?

Try date --debug.

--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Message #23 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Darryl Okahata <darryl_okahata <at> keysight.com>
Cc: 53033 <at> debbugs.gnu.org
Subject: Re: bug#53033: date has multiple "first saturday"s?
Date: Fri, 7 Jan 2022 13:22:04 -0700

Darryl Okahata via GNU coreutils Bug Reports wrote:
> From coreutils 9.0 (note the difference between the "second" and "third"
> saturdays):
...
> $ src/date --debug -d "second saturday"
> date: parsed relative part: +1 seconds

Caution!  The date utility can't parse second due to second being a
unit of time.  The documentation says:

       A few ordinal numbers may be written out in words in some contexts.
    This is most useful for specifying day of the week items or relative
    items (see below).  Among the most commonly used ordinal numbers, the
    word ‘last’ stands for -1, ‘this’ stands for 0, and ‘first’ and ‘next’
    both stand for 1.  Because the word ‘second’ stands for the unit of time
    there is no way to write the ordinal number 2, but for convenience
    ‘third’ stands for 3, ‘fourth’ for 4, ‘fifth’ for 5, ‘sixth’ for 6,
    ‘seventh’ for 7, ‘eighth’ for 8, ‘ninth’ for 9, ‘tenth’ for 10,
    ‘eleventh’ for 11 and ‘twelfth’ for 12.

Inconsistencies like this are why I wish it had never been
implemented.  Best to avoid the syntax completely.

Bob

Message #26 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Darryl Okahata <darryl_okahata <at> keysight.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: "53033 <at> debbugs.gnu.org" <53033 <at> debbugs.gnu.org>
Subject: RE: bug#53033: date has multiple "first saturday"s?
Date: Mon, 10 Jan 2022 19:42:11 +0000

Bob Proulx <bob <at> proulx.com> 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.

  -- Darryl

Message #29 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Darryl Okahata <darryl_okahata <at> keysight.com>
Cc: 53033 <at> debbugs.gnu.org
Subject: Re: bug#53033: date has multiple "first saturday"s?
Date: Mon, 10 Jan 2022 15:11:09 -0700

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

Message #32 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Darryl Okahata <darryl_okahata <at> keysight.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: "53033 <at> debbugs.gnu.org" <53033 <at> debbugs.gnu.org>
Subject: RE: bug#53033: date has multiple "first saturday"s?
Date: Mon, 10 Jan 2022 22:33:50 +0000

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 <at> proulx.com> 
Sent: Monday, January 10, 2022 2:11 PM
To: Darryl Okahata <darryl_okahata <at> keysight.com>
Cc: 53033 <at> 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

Message #35 received at 53033 <at> debbugs.gnu.org (full text, mbox):

From: Paul Vint <pjvint <at> gmail.com>
To: Darryl Okahata <darryl_okahata <at> keysight.com>
Cc: "53033 <at> debbugs.gnu.org" <53033 <at> debbugs.gnu.org>,
 Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#53033: date has multiple "first saturday"s?
Date: Mon, 10 Jan 2022 18:27:11 -0500

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> proulx.com>
> Sent: Monday, January 10, 2022 2:11 PM
> To: Darryl Okahata <darryl_okahata <at> keysight.com>
> Cc: 53033 <at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.