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