GNU bug report logs - #44240
coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

Previous Next

To reply to this bug, email your comments to 44240 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Wandersleb <leo.wandersleb <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific
 date: 2020-09-06
Date: Mon, 26 Oct 2020 12:14:53 -0300

Hi,

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
2020-10-05 Mon 05 Oct 2020 12:00:00 AM -03
2020-10-06 Tue 06 Oct 2020 12:00:00 AM -03
2020-10-07 Wed 07 Oct 2020 12:00:00 AM -03

Regards,

Leo Wandersleb

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Philip Rowlands" <phr+coreutils <at> dimebar.com>
To: "George R Goffe via GNU coreutils Bug Reports" <bug-coreutils <at> gnu.org>
Subject: Re: bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06
Date: Mon, 26 Oct 2020 16:22:43 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.