git日期语法规范

Question

是否有任何关于传递日期语法的规范 要git？例如，什么日期被接受 “ - before”选项“git rev-list”？

假设没有这样的规范，有没有 获取git将日期转换为规范的方法 表单，以便可以检查给定的日期字符串 被解释为人们期待的？ （更新：我 写了一个脚本来做这个，这是可用的 here。）

信息说明：日期解析似乎已实施 在文件date.c中，在git的存储库的根目录中。 “入口点”似乎是一个叫做的函数 approxidate_careful。

Answer 1

据我所知，它没有明确指出，但它似乎接受它可以输出的所有格式，如--date选项的文档中所述：

  

--date=(relative|local|default|iso|rfc|short|raw)

     

仅对以人类可读格式显示的日期生效，例如使用时   --pretty。 log.date config变量设置log的默认值   命令的--date选项。

     

--date=relative显示相对于当前时间的日期，例如“2小时前”。

     

--date=local在用户的本地时区显示时间戳。

     

--date=iso（或--date=iso8601）以ISO 8601格式显示时间戳。

     

--date=rfc（或--date=rfc2822）以RFC 2822格式显示时间戳，通常位于电子邮件中。

     

--date=short仅以YYYY-MM-DD格式显示日期，但不显示时间。

     

--date=raw以内部原始git格式%s %z格式显示日期。

     

--date=default显示原始时区（提交者或作者）的时间戳。

Answer 2

正如您已经发现的，git通常使用近似来解析所有类型的时间。 这允许您编写各种自然到疯狂的方式来指定时间。

这允许你写“六分钟前”或“上周二”甚至“下午茶时间”之类的东西，而且近似通常理解你的意思。除了您已经找到的来源之外，我不知道任何明确的文档。

关于该主题的一篇不错的博客文章是http://www.alexpeattie.com/blog/working-with-dates-in-git/

Answer 3

真实代码位于https://github.com/git/git/blob/master/date.c#L717，并列举了可用的格式，如iso8601，rfc2822以及各种短，本地，原始和默认格式。

Answer 4

可悲的是，Git对它接受的日期和时间格式并不一致。内部规范格式是Unix时间戳（即1970年1月1日午夜以来的秒数）和时区偏移量的组合。

对于指定日期，这有点难以阅读。我使用Git对ISO 8601的解释来获得一种相对容易阅读的格式，并且始终是明确的。根据您使用的命令，您通常可以--date=iso作为minitech noted获取此命令。它看起来像2012-12-26 23:17:23 +0000。

（--date=rfc版本同样明确，因为它只会以相同的方式解释，但包括工作日。我个人反对这样做，因为它允许你指定看起来有效的日期但是当天与日期不符，例如Sun, 26 Dec 2012 01:02:03 +0000 [今天是星期三]。）

对于我认为在任何地方都接受的格式，运行git help commit-tree;该手册页包含以下内容（我稍微重新格式化）：

  

日期格式

     

GIT_AUTHOR_DATE，GIT_COMMITTER_DATE环境变量支持以下日期格式：

     

  

• Git内部格式：它是<unix timestamp> <timezone offset>，其中<unix timestamp>是自UNIX emoch以来的秒数。 <timezone offset>是UTC的正偏移或负偏移。例如，CET（比UTC早两个小时）是+0200。

  

• RFC 2822：RFC 2822所述的标准电子邮件格式，例如Thu, 07 Apr 2005 22:13:13 +0200。

  

• ISO 8601：ISO 8601标准指定的时间和日期，例如2005-04-07T22:13:13。解析器也接受空格而不是T字符。

       

  注意：此外，还会采用以下格式接受日期部分：YYYY.MM.DD，MM/DD/YYYY和DD.MM.YYYY。

  

有些地方使用“近似”，因此不那么挑剔，如michas noted。如果你喜欢深入研究这个代码，那么代码就是Git的date.c（通过发布的Working With Dates in Git链接链接）。例如，以下内容来自git help revisions：

  

指定修订

     

...

     

  
• <refname>@{<date>}，例如master@{yesterday}，HEAD@{5 minutes ago}：引用后缀为@，日期规范括在括号对中（例如{yesterday}，{1 month 2 weeks 3 days 1 hour 1 second ago}或`{1979-02 -26 18:30:00}）指定先前时间点的ref值。 ...
  

Answer 5

请注意＆＃34; date=iso＆＃34;格式不是完全 ISO 8601 请参阅commit＆＃34; 466fb67＆＃34;来自Beat Bolli (bbolli)，适用于Git 2。2。0（2014年11月）

漂亮：提供严格的ISO 8601日期格式

  

Git＆＃34; ISO＆＃34;由于差异很小，日期格式并不真正符合ISO 8601标准，并且它不能由仅ISO 8601的解析器解析，例如，那些XML工具链。

     

＆＃34; --date=iso＆＃34;的输出以这些方式偏离ISO 8601：

     

  
• 空格而不是T日期/时间分隔符
  
• 时区和时区之间的空格
  
• 时区的小时和分钟之间没有冒号
  

     

添加严格的ISO 8601日期格式以显示提交者和作者日期   使用＆＃39; %aI＆＃39;和＆＃39; %cI＆＃39;格式说明符并添加＆＃39; --date=iso-strict＆＃39;或者＆＃39; --date=iso8601-strict＆＃39;日期格式名称。

     

请参阅this thread进行讨论。

Answer 6

Git 2。2。2（2015年1月）在尝试dd/mm/yy或mm/dd/yy之间做出一点改进。

请参阅commit d372395

撰写的Jeff King (peff)

  

近似：将来允许类似ISO的日期

     

当我们解析近似字符串时，我们发现三个数字被“:/-.”之一分开，我们猜测它可能是一个日期。
  我们将这些数字提供给match_multi_number，以检查各种顺序中的日期是否合理（例如dd/mm/yy或mm/dd/yy等）。

     

我们进行的检查之一是查看将来是否超过10天。这已在38035cf (date parsing: be friendlier to our European friends., 2006-04-05, Git 1.3.0)中添加，让我们猜测，如果它目前是2014年4月，则“10/03/2014”可能是3月10日，而不是10月   第三

     

但这有不利之处; 如果您希望对“--until”日期规范过于慷慨，我们可能错误地将“2014-12-01”解析为“2014-01-12”（因为后者是过去的日期）   如果这一年是未来的一年（即两者都是未来的日期），它甚至更加怪异。由于在当前日期之后几个月的变幻莫测   （无论是哪一年）都会被翻转，但之前没有翻过来。

     

此修补程序会删除“将来”检查此表单的日期，让我们始终将其视为yyyy-mm-dd，即使它们将来也是如此。
  这不会影响正常dd/mm/yyyy与mm/dd/yyyy查找，因为此代码路径仅在第一个数字大于70时启动   （即，它必须是一年，不能是日期或月份。）

     

唯一可能的伤亡是“yyyy-dd-mm”不太可能被选为“yyyy-mm-dd”。这可能没关系，但因为：

     

  
1. 只有日期是将来才会出现差异。我们过去更喜欢yyyy-mm-dd日期。
  
2. 目前还不清楚是否有人经常使用yyyy-dd-mm。它不会出现在lists of common date formats in Wikipedia。
中   
3. 即使（2）错误，最好选择类似ISO的日期，因为这与我们在git中的其他地方使用的日期一致。