tag 25560 notabug
close 25560
thanks

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.
> 
> 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?
> 
> 
> 
> 

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