私はいくつかの例を見てきました（これを含む役職) かなり単純なようですが、何を間違っているのかよくわかりません (この投稿は Linux 用だとわかっていますが、dateLinux マシンでコマンドを試したところ、同じ結果になりました)
コマンドと出力の例
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:00UTC+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+7and days(+1 days上記の意味) ではなく、むしろUTC(意味UTC+0) and のようです+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列は同じである必要があります。異なるユーザーは、異なるタイムゾーンで同じ文字列を解釈し、実際には異なる瞬間を取得します。この意味で、結果は異なります。同じ意味で、入力も異なります。