It has to be something messing/interacting with coreutils/date on 19.04 (and probably on Tumbleweed).
I created a new container with 19.04, and then: * apt build-dep coreutils * apt install rsync wget git * git clone git://git.sv.gnu.org/coreutils * cd coreutils * export FORCE_UNSAFE_CONFIGURE=1 # too lazy to adduser * ./boostrap * ./configure * make at the end of the build I ran both the provided date and the just-built one. Both ran correctly: root@u1904:~/coreutils# date --debug +%-Y -d '- 2010 years' date: parsed relative part: -2010 year(s) date: input timezone: system default date: using current time as starting value: '00:30:39' date: using current date as starting value: '(Y-M-D) 2019-04-16' date: starting date/time: '(Y-M-D) 2019-04-16 00:30:39' 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 00:30:39' date: '(Y-M-D) 0009-04-16 00:30:39' = -61874062161 epoch-seconds date: timezone: system default date: final: -61874062161.081576777 (epoch-seconds) date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC) date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC+00) 9 root@u1904:~/coreutils# src/date --debug +%-Y -d '- 2010 years' date: parsed relative part: -2010 year(s) date: input timezone: system default date: using current time as starting value: '00:30:49' date: using current date as starting value: '(Y-M-D) 2019-04-16' date: starting date/time: '(Y-M-D) 2019-04-16 00:30:49' 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 00:30:49' date: '(Y-M-D) 0009-04-16 00:30:49' = -61874062151 epoch-seconds date: timezone: system default date: final: -61874062151.239637280 (epoch-seconds) date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC) date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC+00) 9 I then compiled & ran Asaf's inv-year.c: root@u1904:~# gcc -o inv-year inv-year.c root@u1904:~# ./inv-year time() = 1555375408 localtime() = 2019-04-16 00:43:28 (mday=16 wday=2, isdst=0) struct tm (after adjustment) = 0009-04-16 00:43:28 (mday=16 wday=2, isdst=0) mktime() after date adjustment = -61874061392 So: a pristine 19.04 runs it. My laptop (which is my work machine, full of other packages & programs), does not. Oh -- Assaf, yes, I am very well aware 19.04 has not yet been released. But -- unless we find something critical -- it is basically what will be released in a few days. I do not expect a rebuild of the coreutils package, for example. Cheers, ..C.. On Mon, Apr 15, 2019 at 6:11 PM O. Emmerson <oemmer...@gmx.com> wrote: > > On 15/04/2019 21:55, Assaf Gordon wrote: > > To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper > > issue, can you (and/or others) try the attached C program? > > > > It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment. > > > > Because the adjustment is to year 9 (about 1961 years before epoch), > > the time_t value is negative. perhaps that's the issue? or perhaps > > combined with a specific timezone it becomes problematic? > > For me it gives: > > $ ./inv-year > time() = 1555369320 > localtime() = 2019-04-16 00:02:00 > (mday=16 wday=2, isdst=1) > struct tm (after adjustment) = 0009-04-16 00:02:00 > (mday=16 wday=2, isdst=1) > inv-year: mktime() failed: Value too large for defined data type > > > And debug gives: > > $ 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: '00:04:32' > date: using current date as starting value: '(Y-M-D) 2019-04-16' > date: starting date/time: '(Y-M-D) 2019-04-16 00:04:32' > 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) > 1907-04-16 00:04:32' > date: invalid date ‘- 112 years’ > > > > > -- ..hggdh..