Calculations by "date" are wrong

Happens here too.

Still happens in gutsy
coreutils 5.97

its also in coreutils 6.0 so it's upstream.
If you do:

date -d '11:40 8 minutes'

(so leave out the '+'), it gives the right answer: 11:48
11:40 60 seconds gives 11:41 (correct)
11:40 + 1 day gives correct answer
11:40 1 day gives correct anser.

With day, week, year, you can add the plus sign, (or minus sign) doesn't make any difference.
With seconds, minutes and hours, date does strange things when you add a plus or minus sign.

This is probably an upstream bug.

I meant to write coreutils 6.9 not 6.0

Probably related to bug:
http://savannah.gnu.org/bugs/?11290

but launchpad complains it doesn't recognize this bugtracker so i cant connect this bug to that upstream bug.

I have the same problem on gutsy (coreutils 5.97-5.3ubuntu).

A workaround is to specify as a first operation "0 min" (so without a + or - sign, as Tino suggests) and then the actual operation. e.g. :

      date -d "2007-03-23 21:01 0 min -10 min"

At least for me, it works.

It's all about bison parser in gnulib's getdate.y ... that one is not perfect - and I tried to improve it a bit in past months - 4 bugs solved - that one issue is still not commited to upstream although I have fix prepared. To explain why it is the behaviour like this I'll take one example...
$ date -d '11:40 + 8 minutes'
Tue Jun 27 13:33:00 CEST 2006
it is parsed as 11:40 UTC+0:08 +1 minute...
(as CEST is UTC+2:00 , you will get timeshift +1:53 to 11:40 UTC - which turns to 13:33 CEST)
Similar to that:
$ date -d '11:40 + 8 hours'
Tue Jun 27 14:32:00 CEST 2006
is parsed as 11:40 UTC+0:08 +1 hour
Workaround is easy - to specify timezone after time ... Additionally I expect to propose fix to upstream soon... so hopefully it will be solved soon - but it this parser is a bit fragile thing, so it has to be tested a bit more...

Hi Ondřej,

Did you submit the fix? I do not remember, anymore, and I am not sure what you would be fixing ;-)

Yes and no ... patch to fix the issue was proposed to upstream in the set of date.y patches. However, they didn't accepted full set (separate patches for separate issues with tests were requested) and this one last part is still not submitted. I have the patch ready (at least almost ready), but as far as I remember before submitting the patch I found at least one (although a bit obscure) date format which will be regressed by this change. Anyway - I'll check the patch status today and possibly submit the patch to <email address hidden>. Thanks for reminder.

Well... I submitted the patch with the tests to bug-gnulib mailing list. I think that handling date-format "HH:MM + X minutes" is better than handling "HH:MM +T day ago" (+T means timezone here, +X means relative offset number, HH hours, MM minutes). This is the obscure format currently considered invalid. Just as note: "HH:MM +T yesterday" or "HH:MM +T +X days" works without troubles even in new grammar. It's up on the upstream now.

marking as triaged, patch pending acceptance upstream (gnulib).

Upstream has closed this bug as Won't Fix.

This is the wrong GNU bug (savannah bug 11290). I am pretty sure this has been fixed on Maverick (coreutils 8.5), but I will check. Meanwhile, I am unlinking the above savannah bug from here.

Hi,

 On natty :

$ date --version
date (GNU coreutils) 8.5
$ date -d '11:40'
jeudi 25 août 2011, 11:40:00 (UTC+0200)
$ date -d '11:40 + 8 minutes'
jeudi 25 août 2011, 05:41:00 (UTC+0200)
$ date -d '11:40 + 8 hours'
jeudi 25 août 2011, 06:40:00 (UTC+0200)

Another obscure observation I made on Ubuntu 12.04 (probably affects all previous versions as well):

glaubitz@ubuntu:~$ date -d "11:40 + 1 minutes"
Mon Jun 11 12:41:00 CEST 2012
glaubitz@ubuntu:~$ date -d "11:40 + 2 minutes"
Mon Jun 11 11:41:00 CEST 2012
glaubitz@ubuntu:~$ date -d "11:40 + 3 minutes"
Mon Jun 11 10:41:00 CEST 2012
glaubitz@ubuntu:~$ date -d "11:40 + 4 minutes"
Mon Jun 11 09:41:00 CEST 2012
glaubitz@ubuntu:~$ date -d "11:40 + 5 minutes"
Mon Jun 11 08:41:00 CEST 2012

On a side note, date seems to have trouble on systems where time_t is too small (i.e. 32 bits instead of 64 bits):

glaubitz@debian32:~> lsb_release -rsc
6.0.5
squeeze
glaubitz@debian32:~> uname -a
Linux debian32 3.2.0-0.bpo.2-686-pae #1 SMP Wed May 30 01:20:28 UTC 2012 i686 GNU/Linux
glaubitz@debian32:~> date -d "1000 months ago"
date: invalid date `1000 months ago'
glaubitz@debian32:~> date -d "2000 months ago"
Tue Nov 17 06:29:07 CET 1981
glaubitz@debian32:~> logout
Connection to debian32 closed.
glaubitz@debian64:~> lsb_release -rsc
6.0.5
squeeze
glaubitz@debian64:~> uname -a
Linux debian64 3.2.0-0.bpo.1-amd64 #1 SMP Wed Jan 25 00:15:47 UTC 2012 x86_64 GNU/Linux
glaubitz@debian64:~> date -d "1000 months ago"
Mon Feb 11 01:01:14 CET 1929
glaubitz@debian64:~> date -d "2000 months ago"
Sat Oct 11 01:01:17 LMT 1845

This was tested on Debian Squeeze, but affects Ubuntu as well (tested on Precise, 12.04). I guess this should be reported to upstream and go into a separate bug report.

Adrian

The linked Debian bug has the following comment from the maintainer:

> I will update the documentation in the next version to mention that you
> should never use any of the natural language features.

(I don't think that ever happened, though.)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515764#10