bug#50115: Found the line where it is failing
On line 2160 in `./gnulib/lib/parse-datetime.y`, there's this:
```c
if (Start == (time_t) -1)
{
if (debugging ())
dbg_printf (_("error: adding relative date resulted "
"in an invalid date: '%s'\n"),
debug_strfdatetime (, , dbg_tm,
sizeof dbg_tm));
goto fail;
}
```
This seems to indicate that, if the parsed value is -1, it's
considered an invalid date, but isn't -1 a valid date in epoch
seconds?
Passing --debug to the date shows the correct result, but claims it's invalid:
```sh
$ ./src/date --debug -u -d "1970-12-31T23:59:59+00:00 - 1 year"
date: parsed datetime part: (Y-M-D) 1970-12-31 23:59:59 UTC+00
date: parsed relative part: -1 year(s)
date: input timezone: parsed date/time string (+00)
date: using specified time as starting value: '23:59:59'
date: starting date/time: '(Y-M-D) 1970-12-31 23:59:59 TZ=+00'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: error: adding relative date resulted in an invalid date:
'(Y-M-D) 1969-12-31 23:59:59 TZ=+00'
./src/date: invalid date ‘1970-12-31T23:59:59+00:00 - 1 year’
```
bug#50115: date command arithmetic involving the epoch produces "invalid date"
Using `date --utc --date="..."` with a date specification that decrements by years that should result in epoch=0 (1969-12-31T23:59:59+00:00) produces an "invalid date" error message. The following commands should illustrate the problem: Notice that the only difference between the starting dates is 1 second. ```sh $ date -u -d "1970-12-31T23:59:59+00:00 - 1 year" date: invalid date ‘1970-12-31T23:59:59+00:00 - 1 year’ $ date -u -d "1970-12-31T23:59:58+00:00 - 1 year" Wed Dec 31 11:59:58 PM UTC 1969 ``` The dates are only considered invalid if they fall on epoch=0: ```sh $ date -u -d "1971-12-31T23:59:59+00:00 - 2 year" date: invalid date ‘1971-12-31T23:59:59+00:00 - 2 year’ $ date -u -d "1972-12-31T23:59:59+00:00 - 3 year" date: invalid date ‘1972-12-31T23:59:59+00:00 - 3 year’ ``` Going the other direction seems to work: ```sh $ date -u -d "1969-01-01T00:00:00+00:00 + 1 year" Thu Jan 1 12:00:00 AM UTC 1970 ``` It only seems to error when decrementing by years: ```sh date -u -d "1970-01-01T00:00:01+00:00 - 1 second" Thu Jan 1 12:00:00 AM UTC 1970 ``` It only seems to error when using --utc, because the following works (my time zone is America/Chicago): ```sh $ date -d "Wed Dec 31 06:00:00 PM CST 1970 - 1 year" +%s 0 ```
bug#50085: fatal error: parse-datetime.tab.h: No such file or directory
Thanks for your patience and clarification. I was able to get it working properly with the latest master: RUN git clone --branch master --single-branch https://git.savannah.gnu.org/git/coreutils.git \ && cd coreutils \ && export FORCE_UNSAFE_CONFIGURE=1 \ && ./bootstrap \ && ./configure \ --disable-gcc-warnings \ && make ‐‐‐ Original Message ‐‐‐ On Wednesday, August 18th, 2021 at 11:01 AM, Paul Eggert wrote: > On 8/17/21 4:48 PM, softwarebugreports via GNU coreutils Bug Reports wrote: > > > Thank you for the help! I tried using > > 8002ca7b56acb46b42eeac4a343e112a8ee283cf and the latest commits from master > > You can't combine the latest Coreutils master commit with old Gnulib > > commits like 8002ca7b56acb46b42eeac4a343e112a8ee283cf (2020-09-13). > > Combinations like that are not intended to work. You need to use the > > Gnulib commit given as a submodule in the Coreutils commit.
bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"
On 8/17/21 4:03 PM, L A Walsh wrote: However you want to phrase it, with: --block-size=SIZE I want to have 'ls' 'scale sizes by SIZE before printing them' But that's what --block-size does. Perhaps your request would be more clear if you gave a specific example of what you want and why --block-size doesn't do what you want.
bug#50085: fatal error: parse-datetime.tab.h: No such file or directory
On 8/17/21 4:48 PM, softwarebugreports via GNU coreutils Bug Reports wrote: Thank you for the help! I tried using 8002ca7b56acb46b42eeac4a343e112a8ee283cf and the latest commits from master You can't combine the latest Coreutils master commit with old Gnulib commits like 8002ca7b56acb46b42eeac4a343e112a8ee283cf (2020-09-13). Combinations like that are not intended to work. You need to use the Gnulib commit given as a submodule in the Coreutils commit.
