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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25560 in the body.
You can then email your comments to 25560 AT debbugs.gnu.org in the normal way.

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

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

From: Owen Leibman <eclipsechasers2 <at> yahoo.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: Alphabetic Character Following date -d
Date: Sat, 28 Jan 2017 06:15:58 +0000 (UTC)

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.

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):

date -d a
Sat, Jan 28, 2017  1:00:00 AM

I searched the man and info pages in vain for how the command might be interpreting "a" here.
If there is some place where this is documented and I just missed it, please let me know.
In the meantime, I'll continue.

I tried other letters - "b" through "i" each advanced the displayed time by 1 hour (so "i" was 9:00).
Upper- and lower-case were treated the same.

At "j", I had a surprise:

date -d j
date: invalid date ‘j’

But then I was equally surprised by "k":

date -d k
Sat, Jan 28, 2017 10:00:00 AM

It seems to have picked up where the sequence was broken.
Continuing, "l" advanced to 11:00, and "m" to 12:00 (PM - presumably noon).
Another surprise came with "n":

date -d n
Fri, Jan 27, 2017 11:00:00 PM

From that point, the result marches backwards by an hour each time until "x" reaches 1:00 p.m.
Then "y" matches the output for "m". And "z":

date -d z
Sat, Jan 28, 2017 12:00:00 AM

And, having run out of letters, my test was complete.

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Owen Leibman <eclipsechasers2 <at> yahoo.com>, 25560-done <at> debbugs.gnu.org
Subject: Re: bug#25560: Alphabetic Character Following date -d
Date: Sat, 28 Jan 2017 02:35:59 -0800

Owen Leibman wrote:
> Is the date command behaving as it should for all these examples?

Those letters are military time zone abbreviations, so yes.

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

From: Eric Blake <eblake <at> redhat.com>
To: Owen Leibman <eclipsechasers2 <at> yahoo.com>, 25560 <at> debbugs.gnu.org
Subject: Re: bug#25560: Alphabetic Character Following date -d
Date: Sat, 28 Jan 2017 07:31:43 -0600

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

From: Owen Leibman <eclipsechasers2 <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 "25560-done <at> debbugs.gnu.org" <25560-done <at> debbugs.gnu.org>
Subject: Re: bug#25560: Alphabetic Character Following date -d
Date: Mon, 30 Jan 2017 01:30:09 +0000 (UTC)

What an interesting answer (and the follow-up research)! Thanks.




----- Original Message -----
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Owen Leibman <eclipsechasers2 <at> yahoo.com>; 25560-done <at> debbugs.gnu.org
Sent: Saturday, January 28, 2017 2:35 AM
Subject: Re: bug#25560: Alphabetic Character Following date -d

Owen Leibman wrote:

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

Those letters are military time zone abbreviations, so yes.

Previous Next

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