Bug 1004549

Summary:	date --date="$(date)" fails
Product:	[Fedora] Fedora	Reporter:	Quentin Armitage <quentin>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	19	CC:	admiller, codonell, fweimer, jakub, kdudka, kzak, law, ooprala, ovasik, pbrady, p, pfrankli, quentin, schwab, spoyarek, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-09 15:13:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Quentin Armitage 2013-09-04 22:01:50 UTC

Description of problem:
date --date="$(date)" reports the following error:
date: invalid date ‘Wed  4 Sep 22:45:45 BST 2013’

This worked without a problem on F18

Version-Release number of selected component (if applicable):
coreutils-8.21-11.fc19.x86_64

F18 version without the problem:
coreutils-8.17-8.fc18.armv5tel (I don't have an Intel based F18 system)

How reproducible:
Always

Steps to Reproduce:
1. date --date="$(date)"
2.
3.

Actual results:
Error message as above

Expected results:
Works successfully, as it did in F18.

Additional info:
Actually, what I want to do is something more sensible, but above is the simplest example of the error I have found. What I want to do is:
touch next_run.$$ --date="$(date -r .last_run) + 1 day"

I have discovered that adding -R to the date command allows it to work, i.e.:
touch next_run.$$ --date="$(date -Rr .last_run) + $DONT_RUN_TIME"

but I thought it worth filing this bug, since I can't see any reference to the functionality being removed, and it seems to me that it ought to work.

Comment 1 Ondrej Vasik 2013-09-09 11:10:43 UTC

Thanks for the detailed report, but I believe that this is not a bug in coreutils date. This format is simply not covered by flex getdate parser - and probably there is some difference in LC_TIME between F18 and F19 - could you please provide the locales which produce the format "Wed  4 Sep 22:45:45 BST 2013"?

On my machine I'm getting "Wed  Sep  4 22:45:45 BST 2013" which is considered valid... I'm quite sure that supporting both sides of the date would result in disambiguation, therefore I think the "good" way is to fix the date output for the locale. 

In any case - see
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e which explains the reasons for the most of the format failures.

Comment 2 Quentin Armitage 2013-09-09 13:39:44 UTC

It appears that I must have been wrong about which system I was using, since my F18 systems are now failing in the same way as F19, but my F16 systems are not having the problem.

My locales are are follows:
F19:   LANG=en_GB.UTF-8
F18:   LANG=en_GB.utf8
F16:   LANG=en_GB.utf8

F19:   LC_TIME=en_GB.UTF-8
F18:   LC_TIME=en_GB.utf8
F16:   LC_TIME=en_GB.utf8

Output of locale LC_TIME

F19
=====================================================================
Sun;Mon;Tue;Wed;Thu;Fri;Sat
Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday
Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec
January;February;March;April;May;June;July;August;September;October;November;December
am;pm
%a %d %b %Y %T %Z
%d/%m/%y
%T
%l:%M:%S %P %Z






0
S
7
19971130
4
2
2
1

%a %e %b %H:%M:%S %Z %Y
UTF-8
=====================================================================

F18
=====================================================================
Sun;Mon;Tue;Wed;Thu;Fri;Sat
Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday
Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec
January;February;March;April;May;June;July;August;September;October;November;December
AM;PM
%a %d %b %Y %T %Z
%d/%m/%y
%T
%l:%M:%S %P %Z






0
S
7
19971130
4
2
2
1

%a %e %b %H:%M:%S %Z %Y
UTF-8
=====================================================================

F16
=====================================================================
Sun;Mon;Tue;Wed;Thu;Fri;Sat
Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday
Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec
January;February;March;April;May;June;July;August;September;October;November;December
AM;PM
%a %d %b %Y %T %Z
%d/%m/%y
%T
%l:%M:%S %P %Z






0
S
7
19971130
4
2
2
1

%a %b %e %H:%M:%S %Z %Y
UTF-8
=====================================================================

So I take it that it is the penultimate line for LC_TIME on F18 and F19,
%a %e %b %H:%M:%S %Z %Y
which is the problem, and that F16 with
%a %b %e %H:%M:%S %Z %Y
is fine.

The addition of date format as "%a %e %b ..." appears to have been done in https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ea32912bbc5ef89816a61b6d13e53403355f86a6

Comment 3 Ondrej Vasik 2013-09-09 13:54:00 UTC

Ok, thanks for the additional information, reassigning to glibc, so the maintainers can explain the reasons for this change. It might be pretty hard to get the already fragile grammar of getdate.y flex parser to work with this new format.

Comment 4 Pádraig Brady 2013-09-09 15:13:18 UTC

I would say not a bug.

To parse the output of date, you need to specify an invariant format with -R etc.
This is explained at:
http://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html