What I want to do is supply a date and time, and then subtract a time from that.
Here is what I tried first:
date -d "2018-12-10 00:00:00 - 5 hours - 20 minutes - 5 seconds"
This results in
2018-12-10 06:39:55 - It added 7 hours. Then subtracted 20:05 minutes.
After reading the
info page of
date, I thought I have it fixed with this:
date -d "2018-12-10T00:00:00 - 5 hours - 20 minutes - 5 seconds"
But, same result. Where does it even get the 7 hours from?
I tried other dates as well because I thought maybe we had 7200 leap seconds on that day, who knows lol. But same results.
A few more examples:
$ date -d "2018-12-16T00:00:00 - 24 hours" +%Y-%m-%d_%H:%M:%S 2018-12-17_02:00:00 $ date -d "2019-01-19T05:00:00 - 2 hours - 5 minutes" +%Y-%m-%d_%H:%M:%S 2019-01-19_08:55:00
But here it becomes interesting. If I omit the time on input, it works fine:
$ date -d "2018-12-16 - 24 hours" +%Y-%m-%d_%H:%M:%S 2018-12-15_00:00:00 $ date -d "2019-01-19 - 2 hours - 5 minutes" +%Y-%m-%d_%H:%M:%S 2019-01-18_21:55:00 $ date --version date (GNU coreutils) 8.30
What am I missing?
Update: I've added a
Z at the end, and it changed the behaviour:
$ date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S 2019-01-19_04:00:00
I'm still confused though. There is not much about this in the GNU info page about date.
If no UTC relation information is given with a time representation, the time is assumed to be in local time.
Which is what I want. My local time is set correctly too. I'm not sure why date would mess with the timezone at all in this simple case of me supplying a datetime and wanting to subtract something off of it. Shouldn't it subtract the hours from the date string first? Even if it does convert it to a date first and then does the subtraction, if I leave out any subtractions I get exactly what I want:
$ date -d "2019-01-19T05:00:00" +%Y-%m-%d_%H:%M:%S 2019-01-19_05:00:00
So IF this truly is a timezone issue, where does that madness come from?