在这个问题上有一个开放的错误。如果您从源代码构建了 git,test-date
则包含一个实用程序。以下是通过它运行各种日期的一些结果(注意 - 18 号不再是我的断点,所以使用 19 号):
$ ./test-date approxidate "2013-3-01 0am"
2013-3-01 0am -> 2013-03-01 19:22:21 +0000
$ ./test-date approxidate "2013-3-11 0am"
2013-3-11 0am -> 2013-03-11 19:22:21 +0000
$ ./test-date approxidate "2013-3-19 0am"
2013-3-19 0am -> 2013-03-03 19:22:21 +0000
很明显,在所有情况下时间都是有问题的,所以让我们修正一下时间:
$ ./test-date approxidate "2013-3-01 0:00"
2013-3-01 0:00 -> 2013-03-01 08:00:00 +0000
$ ./test-date approxidate "2013-3-19 0:00"
2013-3-19 0:00 -> 2013-03-19 07:00:00 +0000
看起来好一点,我们未来的日期不再严重不正确,但时间与我的时区有关,并且在有和没有 DST 之间有所不同(E:对于任何未来的读者,DST 转变发生在 2013-03-10 ,所以这些日期确实包含了转变)。
$ ./test-date approxidate "2013-3-19 0:00 +0000"
2013-3-19 0:00 +0000 -> 2013-03-19 00:00:00 +0000
现在我们的约会看起来好多了。如果我确实希望时区生效,现在可以轻松更改为-0800
/ -0700
、PST
、PDT
或任何其他时区。
简而言之,有两个问题:
- 您的时间没有被正确解析。一旦包含了时间组件,git 在解析日期方面就会变得更加智能。
在解析任何日期的过程中,git 会丢弃你的并在当月的某一天dd
使用你的:mm
$ ./test-date approxidate "2013-3-20"
2013-3-20 -> 2013-03-03 19:22:21 +0000
$ ./test-date approxidate "2013-4-19"
2013-4-19 -> 2013-03-04 19:22:21 +0000
$ ./test-date approxidate "2013-4-32"
2013-4-32 -> 2013-03-04 19:22:21 +0000
您的问题应该可以通过固定时间并根据意图添加时区来解决。