date+%-Y -d "- N years" errors when N > 111

[O. Emmerson]

I have been using 'date +%-Y -d "- 2010 years" in a script for years but today after using the script after upgrading to disco it has failed.

After some experimentation it succeeds with upto 111 years but fails from 112 onwards.

Error given is:

'date: invalid date '- 112 years'.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: coreutils 8.30-1ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-11.12-generic 5.0.6
Uname: Linux 5.0.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Sun Apr 14 10:59:36 2019
InstallationDate: Installed on 2017-10-08 (553 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2)
SourcePackage: coreutils
UpgradeStatus: Upgraded to disco on 2019-04-13 (1 days ago)

BYPASS (probable, not confirmed in all possible scenarios):

use TZ=UTC:

export TZ=UTC, or env TZ=UTC program

[Sebastien Bacher (seb128)]

Thank you for your bug report, that sounds like an upstream issue and probably worth reporting on https://lists.gnu.org/archive/html/bug-coreutils/

[O. Emmerson (oemmerson)]

Ok, it is now reported upstream:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35289

[O. Emmerson (oemmerson)]

I got a reply to my bug report on gnu.org which says:

"
From:
Paul Eggert <email address hidden>
It works for me with coreutils 8.31 on RHEL 7 x86-64:

$ date +%-Y -d "- 2010 years"
9

Most likely you are running on a 32-bit machine, and dates in the year 9
cannot be represented in a 32-bit timestamp. So a simple fix would be
for you to switch to a 64-bit machine.
"

I am using 64bit Ubuntu though.

I have downloaded and compiled coreutils 8.31 to see if the command worked for me in the upgraded version but the error remains the same.

[C de-Avillez (hggdh2)]

I have ran a few tests on 16.04, 18.04, 18.10, and 19.04 (all X86_64):

16.04:

root@u1604:~# date +%-Y -d '- 2010 years'
9
root@u1604:~# date --version
date (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.04:

root@bionic:~# date +%-Y -d '- 2010 years'
9
root@bionic:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.10:

root@u1810:~# date +%-Y -d '- 2010 years'
9
root@u1810:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

19.04:

cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Interestingly, it is also failing on git head:

130 cerdea@piatam:/data/buildd/coreutils$ src/date +%-Y -d '- 2010 years'
src/date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ src/date --version
date (GNU coreutils) 8.31.12-6d78a
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

[Paul Eggert (eggert-cs)]

Assaf Gordon reports that he did not reproduce the problem on Ubuntu Live amd64 dated 2019-04-13 22:28; see:

https://debbugs.gnu.org/35289#25

Perhaps the output of 'env' and 'strace' will help the original reporter diagnose the problem.

[O. Emmerson (oemmerson)]

Thanks for the testing C de-Avillez.

Here's the output of debug:

$ date +%-Y -d "- 112 years" --debug
date: parsed relative part: -112 year(s)
date: input timezone: system default
date: using current time as starting value: '20:47:40'
date: using current date as starting value: '(Y-M-D) 2019-04-15'
date: starting date/time: '(Y-M-D) 2019-04-15 20:47:40'
date: error: adding relative date resulted in an invalid date: '(Y-M-D) 1907-04-15 20:47:40'
date: invalid date ‘- 112 years’

[O. Emmerson (oemmerson)]

Here's the strace output.

[C de-Avillez (hggdh2)]

Further exchange on https://debbugs.gnu.org/35289 suggests this is a libc6 problem, not a coreutils/date one.

Assaf Gordon (upstream) provided a test that can be run (attached here are inv-year.c). If it fails on the mktime() call, then it is not 'date', but libc6.

I also found that setting TZ=UTC seems to bypass the problem; in my primary test machine, TZ was unset (but I was still getting a failure). Setting TZ to UTC, or an invalid value, works. Setting TZ=America/Chicago fails (perhaps related to DST?):

cerdea@piatam:~/Downloads$ env TZ=UTC date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: TZ="UTC" environment value
date: using current time as starting value: '17:28:13'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 17:28:13'
date: warning: when adding relative months/years, it is recommended to specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 17:28:13'
date: '(Y-M-D) 0009-04-16 17:28:13' = -61874001107 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: -61874001107.571934909 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 17:28:13 (UTC)
date: final: (Y-M-D) 0009-04-16 17:28:13 (UTC+00)
9
cerdea@piatam:~/Downloads$ env TZ=blah/blah date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: TZ="blah/blah" environment value
date: using current time as starting value: '17:28:26'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 17:28:26'
date: warning: when adding relative months/years, it is recommended to specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 17:28:26'
date: '(Y-M-D) 0009-04-16 17:28:26' = -61874001094 epoch-seconds
date: timezone: TZ="blah/blah" environment value
date: final: -61874001094.525620784 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 17:28:26 (UTC)
date: final: (Y-M-D) 0009-04-16 17:28:26 (UTC+00)
9
cerdea@piatam:~/Downloads$ env TZ=America/Chicago date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: TZ="America/Chicago" environment value
date: using current time as starting value: '12:28:37'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 12:28:37'
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) 0009-04-16 12:28:37'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:~/Downloads$

and, with Assaf's test:

cerdea@piatam:~/Downloads$ env TZ=UTC ./inv-year
time() = 1555435812
localtime() = 2019-04-16 17:30:12
              (mday=16 wday=2, isdst=0)
struct tm (after adjustment) = 0009-04-16 17:30:12
                               (mday=16 wday=2, isdst=0)
mktime() after date adjustment = -61874000988
cerdea@piatam:~/Downloads$ env TZ=blahblah ./inv-year
time() = 1555435821
loc...

[C de-Avillez (hggdh2)]

Assaf's test, attached.

[Sebastien Bacher (seb128)]

Trying on the current fedora 30 livecd they have the same issue

[C de-Avillez (hggdh2)]

re-assigning bug to glibc