On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote: > for some reason I get an error with one specific date but not with others: > > $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date > -d"$d" ); done; done > 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04 > 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04 > 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04 > 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04 > date: invalid date ‘2020-09-06’ > 2020-09-06 > 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03
The clue is the change in timezone offset from -04 to -03. The only location I could find which switched on 2020-09-06 was Chile, so we can reproduce the problem with: $ TZ=Chile/Continental date --debug -d 2020-09-06 date: parsed date part: (Y-M-D) 2020-09-06 date: input timezone: TZ="Chile/Continental" environment value date: warning: using midnight as starting time: 00:00:00 date: error: invalid date/time value: date: user provided time: '(Y-M-D) 2020-09-06 00:00:00' date: normalized time: '(Y-M-D) 2020-09-06 01:00:00' date: -- date: possible reasons: date: non-existing due to daylight-saving time; date: numeric values overflow; date: missing timezone date: invalid date ‘2020-09-06’ Notice that, in Chile's DST rules, the time jumps from 23:59:59 to 01:00:00: $ zdump -v Chile/Continental | grep 2020 Chile/Continental Sun Apr 5 02:59:59 2020 UT = Sat Apr 4 23:59:59 2020 -03 isdst=1 gmtoff=-10800 Chile/Continental Sun Apr 5 03:00:00 2020 UT = Sat Apr 4 23:00:00 2020 -04 isdst=0 gmtoff=-14400 Chile/Continental Sun Sep 6 03:59:59 2020 UT = Sat Sep 5 23:59:59 2020 -04 isdst=0 gmtoff=-14400 Chile/Continental Sun Sep 6 04:00:00 2020 UT = Sun Sep 6 01:00:00 2020 -03 isdst=1 gmtoff=-10800 Therefore there is no valid time "00:00:00", and this is the "non-existing due to daylight-saving time" case which date --debug reports. This is an FAQ, which often crops up twice per year: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Cheers, Phil
