我见过几个例子（包括这个邮政) 它看起来很简单，但我不太明白我做错了什么（我知道那篇文章是关于 Linux 的，但我date在 Linux 机器上尝试使用该命令并得到相同的结果）
示例命令和输出
me@mymachine~$ gdate -d '2019-10-19 01:37:02 +7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-19 14:37:02
我期望结果以 开头2019-10-26。所以看起来它没有解析我的输入，对吗？
更奇怪的是（至少对我来说），如果我去掉输入的时间部分，它会按预期工作
me@mymachine~$ gdate -d '2019-10-19 +7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-26 00:00:00
答案1
分析
我在 Debian 9 中做了一些测试，研究了man 1 date和info date。后者包含有关如何2019-10-19 01:37:02 +7 days解释诸如的字符串的更多信息。
初步说明：
- 我的答案使用是
date因为这是 Debian 中的工具。（用于alias date=gdate测试我的命令，而gdate无需每次都编辑它们）。 - 看来您的时区大致相当于
TZ=UTC+4。
我尝试复制你的结果：
$ date -d '2019-10-19 01:37:02 +7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-19 20:37:02
我的结果不同，这表明时区很重要。要真正复制您的结果：
$ TZ=UTC+4 date -d '2019-10-19 01:37:02 +7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-19 14:37:02
解释
事实证明，+7您的“行为不当”命令被解释为，UTC+7并被days解释为+1 days。比较：
$ TZ=UTC+4 date -d '2019-10-19 01:37:02 UTC+7 +1 days' +"%Y-%m-%d %H:%M:%S"
2019-10-19 14:37:02
（注TZ=UTC+4：UTC-04:00而UTC+7在字符串中意味着UTC+07:00. 解释与标志不一致的问题这里。
这个神秘的结果现在不再那么神秘了。
怪癖
真正奇怪的是：
$ TZ=UTC+4 date -d '2019-10-19 01:37:02 UTC+7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-25 21:37:02
显然它不是UTC+7和days（意思+1 days同上）而是UTC（意思UTC+0）和+7 days：
$ TZ=UTC+4 date -d '2019-10-19 01:37:02 UTC+0 +7 days' +"%Y-%m-%d %H:%M:%S"
2019-10-25 21:37:02
解决方案
将+7 days子字符串移至开头，使其出现在 之前01:37:02。这种方式+7不会被解释为UTC+7：
$ date -d '2019-10-19 +7 days 01:37:02' +"%Y-%m-%d %H:%M:%S"
2019-10-26 01:37:02
现在01:37:02，输入字符串将根据任何date认为正确的时区进行解释。结果*对于我在欧洲、美国、澳大利亚或任何地方的用户来说都应该是相同的。这就是我放弃的原因TZ=UTC+4，这不再重要了。
*我的意思是字符串打印的date应该是相同的。不同的用户会在不同的时区解释相同的字符串，并且实际上他们会得到不同的时刻。从这个意义上讲，他们的结果是不同的。从同样意义上讲，他们的输入也是不同的。