Hide Forgot
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.
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.
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
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.
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