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
