GNU bug report logs - #25560
Alphabetic Character Following date -d

Previous Next

Full log

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

From: Owen Leibman <eclipsechasers2 <at> yahoo.com>
To: Eric Blake <eblake <at> redhat.com>, 
 "25560 <at> debbugs.gnu.org" <25560 <at> debbugs.gnu.org>
Subject: Re: bug#25560: Alphabetic Character Following date -d
Date: Mon, 30 Jan 2017 01:33:39 +0000 (UTC)

Thank you so much for the tip about --debug (agree with your assessment),
and for doing the further research in Cygwin.




----- Original Message -----
From: Eric Blake <eblake <at> redhat.com>
To: Owen Leibman <eclipsechasers2 <at> yahoo.com>; 25560 <at> debbugs.gnu.org
Sent: Saturday, January 28, 2017 5:31 AM
Subject: Re: bug#25560: Alphabetic Character Following date -d

On 01/28/2017 12:15 AM, Owen Leibman wrote:
> Testing a script to see how it handled invalid data, I had it execute the command:
> date -d "x023-04-05 01:00"
> Somewhat surprisingly, this was not treated as an error. The response was:
> Tue Apr  4 06:07:02 LMT 0023
> 
> This happened on a Ubuntu system using coreutils-8.25.
> However, I was not able to duplicate it on a Cygwin system using coreutils 8.26,
> Where the date was flagged as invalid.
> So, at a guess, this was a bug that was fixed in 8.26.

Odd, because running the latest coreutils.git on 64-bit Linux, I see:

$ src/date --debug -d "x023-04-05 01:00"
date: parsed zone part: TZ=+11:00
date: parsed date part: (Y-M-D) 0023-04-05
date: parsed time part: 01:00:00
date: input timezone: +11:00 (set from parsed date/time string)
date: using specified time as starting value: '01:00:00'
date: starting date/time: '(Y-M-D) 0023-04-05 01:00:00 TZ=+11:00'
date: '(Y-M-D) 0023-04-05 01:00:00 TZ=+11:00' = -61433287200 epoch-seconds
date: output timezone: -06:00 (set from system default)
date: final: -61433287200.000000000 (epoch-seconds)
date: final: (Y-M-D) 0023-04-04 14:00:00 (UTC0)
date: final: (Y-M-D) 0023-04-04 08:09:24 (output timezone TZ=-06:00)
Tue Apr  4 08:09:24 LMT 0023

vs. this in a VM on 32-bit Cygwin with date 8.26:

$ date --debug -d "x023-04-05 01:00"
date: parsed zone part: TZ=+11:00
date: parsed date part: (Y-M-D) 0023-04-05
date: parsed time part: 01:00:00
date: input timezone: +11:00 (set from parsed date/time string)
date: using specified time as starting value: '01:00:00'
date: error: invalid date/time value:
date:     user provided time: '(Y-M-D) 0023-04-05 01:00:00 TZ=+11:00'
date:        normalized time: '(Y-M-D) 0023-04-05 01:00:00 TZ=+11:00'
date:
date:      possible reasons:
date:        numeric values overflow;
date:        incorrect timezone
date: invalid date 'x023-04-05 01:00'

Okay, so maybe the problem is because it's a 32-bit environment.  Firing
up my 64-bit VM, and Cygwin now gives:
Tue, Apr  4, 0023  8:09:24 AM

Aha - that explains it! 32-bit time_t on 32-bit Cygwin overflows, while
64-bit time_t did not.

> 
> But, not so fast - the following commands give identical surprising results with both versions
> (for convenience, I set my time zone to UTC before issuing these commands):

The new 'date --debug' option in coreutils 8.26 is amazing; it explains
all of these questions you have.


> Is the date command behaving as it should for all these examples?

Yes.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Previous Next

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