git commit命令中的--date参数应该使用什么格式？

Question

我需要覆盖Git提交的日期，所有文档都指向--date参数，但是没有一个让人了解适当格式的线索。我已经尝试了我能想到的每种排列方式，但我得到了：

"fatal: invalid date format:"

每一个都出现错误。

- v010dya

---

有些回答部分回答了我的问题。我刚刚检查过，它可以工作。顺便说一下，你不需要在那里放上星期几（那会很痛苦）。 - v010dya

Answer 1

Git 2.6+（2015年第三季度）新增了一个选项。

请查看提交 e4f031e（2015年6月30日），以及提交 aa1462c，提交 a5481a6，提交 b7c1e11（2015年6月25日），作者为Jeff King (peff)。
^{（由Junio C Hamano -- gitster --合并于提交 d939af1，2015年8月3日）}

介绍“格式”日期模式

这将直接将格式传递给strftime。除了更加灵活外，主要优点是您的系统strftime可能更了解您所在地区的首选格式（例如，如何拼写星期几）。

--date = format：... 将格式...提供给您的系统strftime。使用--date = format：％c以显示日期在您的系统语言环境的首选格式中。有关格式占位符的完整列表，请参见strftime手册。 Davide Cavestro在评论中提出了以下示例：

git commit -m "Test" --date=format:relative:5.hours.ago 

---

原始回答（2014 年中旬）

--date 选项（在 git1.7.0 中引入，commit 02b47cd，时间为 2009 年 12 月）使用与 GIT_AUTHOR_DATE 相同的格式，并测试了 commit 96b2d4f 中的日期格式：

您可以在那里看到接受的各种格式：

• rfc2822: Mon, 3 Jul 2006 17:18:43 +0200
• iso8601: 2006-07-03 17:18:43 +0200
• local: Mon Jul 3 15:18:43 2006
• short: 2006-07-03 (not in 1.9.1, works in 2.3.0)

• relative: see commit 34dc6e7:

  5.seconds.ago, 
  2.years.3.months.ago, 
  '6am yesterday'
  

• raw: see commit 7dff9b3 (git 1.6.2, March 2009)
  internal raw git format - seconds since epoch plus timezone
  (put another way: 'date +"%s %z"' format)

• default: Mon Jul 3 17:18:43 2006 +0200

---

ADTC在评论区提问并回答：

本地时间格式是否接受2006-07-03 15:18:43？

是的，它可以工作，并自动采用本地时区。
使用这种格式，我不需要关心是星期几（Sun，Mon等）。

- VonC

---

它是否接受2006-07-03 15:18:43作为本地时间？此外，什么是相对时间和原始时间格式？ - ADTC

回答我自己的第一个问题，是的，它可以工作，并且会自动采用本地时区。使用这种格式，我不需要关心是星期几（周日、周一等）。 - ADTC

@ADTC 我已经添加了相对日期格式和原始日期格式的链接和参考资料。我已将您的评论包含在答案中，以增加其可见性。 - VonC

@CiroSantilli 不确定：这可能是一个很好的独立问题。我将用1.9.4版本进行测试。 - VonC

它的工作方式类似于 git commit -m "Test" --date=format:relative:5.hours.ago。 - Davide Cavestro

Answer 2

简单的例子：

GIT_AUTHOR_DATE='2015-04-19 17:18:43 +0200' GIT_COMMITTER_DATE='2015-04-19 17:18:43 +0200' git commit -m 'Commit message'

- Dmytro Melnychuk

---

使用环境变量似乎是设置提交日期的唯一方法，没有其他参数选项。 - Jarl

Answer 3

日期格式在Documentation/date-formats.txt（man git commit）中文档不够详细，而且解析方式非常“人性化”。唯一有效的方法是阅读date.c源代码并进行试验。

VonC在2.3.0版本中没有提到的要点：

- 仅包含数字的日期根据数字位数进行解析： - 2位数字：19YY，对于YY >= 73，使用当前月份、日期和时间。否则报错或使用当前日期。 - 4位数字：YYYY，对于YYYY >= 1973，<= 2099。 - 大于8位数字直到某个较小的限制（TODO 是哪个？）：UNIX时间（自1970年以来的秒数） - @<digits> +0000：UNIX时间 - 这似乎是直接输入UNIX时间的最佳方式。 - 2 ** 64-2（TODO为什么不是-1？）是不会导致提交错误的最大值。时间戳存储在C long中。 - git log显示非常大的值（大约在2 ^ 55 TODO哪里？）为1970年，即使git cat-file -p HEAD显示存储了正确的数字，因此似乎是日期转换的限制。 - 对于大于2 ** 63-1（最大正有符号长整型）的任何值，尝试推送到GitHub都会失败，并显示“date causes integer overflow”。在该日期提交到GitHub（GitHub 由于某种原因无法显示非常大的日期） - VonC指出这是一个遗憾，因为它阻止了负日期（是否可以将Git提交设置为具有1970年之前的时间戳？），这可以用于将旧软件迁移到Git。 - tea：今天下午5点 :-)

- Ciro Santilli OurBigBook.com

---

请注意，对于依赖日期的Git仓库（例如此链接：http://stackoverflow.com/q/29385441/6309），1970年之前的日期会更好：https://dev59.com/sGEh5IYBdhLWcg3w_nyv#24977895。 - VonC

@VonC：不错的链接。我从未想过版本控制自60年代/70年代以来就存在http://programmers.stackexchange.com/questions/184695/when-was-source-control-invented，并且文字可以追溯到公元前-3200年。如果他们想将汉谟拉比的代码迁移到Git，怎么办？ :-)（啊，刚刚发现已经有人这样做了：https://github.com/elia/hammurabi/blob/master/lib/hammurabi/code.txt，但是失去了时间戳） - Ciro Santilli OurBigBook.com

Answer 4

你可以写：「昨天」、「2 天前」或者「1 周前」，或者你可以用短横线输入特定日期。你可以按照传统的顺序来输入，例如 2023 年 6 月 19 日。

- TJ Relly

Answer 5

以下缩写形式都可以使用：

1. <month>/<day>
2. <month>-<day>
3. <day>.<month>

当没有歧义时，即<day>大于12，<month><day>的顺序无关紧要，分隔符可以是任何一个'/'、'-'或'.'。

否则，对于<day>.<month>，使用'.'作为分隔符，对于<month>-<day>，使用'/'或'-'作为分隔符。

因此，"1.7"将被视为"7月1日"，而"1/7"将被视为"1月7日"。

请参见v1.3.0相关提交：

我们从#git频道的欧洲朋友那里了解到，dd.mm.yyyy是他们的标准。当分隔符为“.”时，我们更喜欢dd.mm.yyyy而不是mm.dd.yyyy；否则，mm/dd/yy[yy]优先于dd/mm/yy[yy]。这也适用于其他接受日期输入的命令，例如：显示自2月4日以来的日志：

git log --since 2/4

- ryenus