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