git に渡される日付の構文に関する仕様はありますか? たとえば、「git rev-list」の「--before」オプションで受け入れられる日付は?
そのような仕様がないと仮定すると、与えられた日付文字列が期待どおりに解釈されていることを確認できるように、git で日付を正規の形式に変換する方法はありますか? (更新: これを行うためのスクリプトを作成しまし た。こちらから入手できます。)
情報メモ: 日付の解析は、git のリポジトリのルートにあるファイル date.c に実装されているようです。「エントリーポイント」は approxidate_careful という関数のようです。
私が知る限り、どこにも明示的に記載されていませんが、--dateオプションのドキュメントに記載されているように、出力できるすべての形式を受け入れるようです:
--date=(relative|local|default|iso|rfc|short|raw)を使用する場合など、人間が判読できる形式で表示される日付に対してのみ有効です
--pretty。log.dateconfig 変数は、log コマンドの--dateオプションのデフォルト値を設定します。
--date=relative「2 時間前」など、現在の時刻に対する日付を表示します。
--date=localユーザーのローカル タイムゾーンでタイムスタンプを表示します。
--date=iso(または--date=iso8601) は、タイムスタンプを ISO 8601 形式で表示します。
--date=rfc(または--date=rfc2822) RFC 2822 形式のタイムスタンプを示します。これは、電子メール メッセージでよく見られます。
--date=shortYYYY-MM-DD形式で日付のみを表示し、時刻は表示しません。
--date=raw内部 raw git フォーマット%s %z形式で日付を表示します。
--date=default元のタイムゾーン (コミッターまたは作成者のいずれか) でタイムスタンプを表示します。
実際のコードはhttps://github.com/git/git/blob/master/date.c#L717にあり、iso8601、rfc2822などの使用可能な形式と、さまざまな短い形式、ローカル形式、raw形式、デフォルト形式を列挙しています。
残念ながら、Gitはどの日付と時刻の形式を受け入れるかについて一貫性がありません。内部の標準形式は、Unixタイムスタンプ（つまり、1970年1月1日の午前0時からの秒数）とタイムゾーンオフセットの組み合わせです。
日付を指定するために、それはやや読みにくいです。GitによるISO8601の解釈を使用して、比較的読みやすく、常に明確な形式にします。使用しているコマンドによっては、minitechが指摘しているようにこれを取得できることが--date=isoよくあり ます。のようになります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エモックからの秒数です。<timezone offset>UTCからの正または負のオフセットです。たとえば、CET（UTCより2時間進んでいます）は+0200です。RFC 2822：たとえば、RFC2822で説明されている標準の電子メール形式
Thu, 07 Apr 2005 22:13:13 +0200。ISO 8601：たとえば、ISO8601標準で指定されている日時
2005-04-07T22:13:13。パーサーは、T文字の代わりにスペースも受け入れます。注：さらに、日付部分は次の形式で受け入れられます：
YYYY.MM.DD、、MM/DD/YYYYおよびDD.MM.YYYY。
michasが 指摘したように、一部の場所では「概算」を使用しているため、煩わしさが少なくなっています。これを掘り下げたい場合は、コードはGitにあります（GitリンクmichasのWorking With Datesdate.cを介したリンク）。たとえば、以下はからです：git help revisions
リビジョンの指定
…</p>
<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}）は、前の時点での参照の値を指定します。…</li>
date=iso" " 形式は正確には ISO 8601ではないことに注意してください。Git 2.2.0 (2014 年 11 月) については、Beat Bolli ( )
の
commit " 466fb67 "を参照してください。bbolli
Git の "ISO" 日付形式は、わずかな違いにより実際には ISO 8601 標準に準拠しておらず、ISO 8601 のみのパーサー (XML ツールチェーンのパーサーなど) では解析できません。
" " からの出力は
--date=iso、次の点で ISO 8601 から逸脱しています。
T日付/時刻区切り文字の代わりにスペース- 時間とタイムゾーンの間のスペース
- タイムゾーンの時間と分の間にコロンはありません
コミッターと作成者の日付を表示するための厳密な ISO 8601 日付形式を追加します。
'%aI' および ' ' 形式指定子を使用し、' ' または ' ' 日付形式名%cIを追加します。--date=iso-strict--date=iso8601-strict議論については、このスレッドを参照してください。
dd/mm/yyGit 2.2.2 (2015 年 1 月) では、 と のどちらかを決定しようとするときに小さな改善がもたらされmm/dd/yyます。
Jeff Kingによって書かれたコミット d372395を参照してください( )peff
approxidate: 遠い将来の ISO のような日付を許可します
おおよその文字列を解析していて、"
:/-." のいずれかで区切られた 3 つの数字を見つけた場合、それは日付である可能性があると推測します。
数値を にフィードしmatch_multi_number、さまざまな順序 (たとえば、dd/mm/yyまたはmm/dd/yyなど) で日付として意味があるかどうかをチェックします。私たちが行うチェックの 1 つは、それが 10 日以上先の日付であるかどうかを確認することです。これは38035cf (date parsing: be Friendlyer to our European friends., 2006-04-05, Git 1.3.0)
10/03/2014で追加されたもので、現在が 2014 年 4 月である場合、" " はおそらく 3 月 10 日ではなく、3 月 10 日であると推測できます。 10月3日。ただし、これには欠点があります。日付の指定に過度に寛容になりたい場合は、"
--until" を誤って " " として解析する可能性があります2014-12-01(2014-01-12後者は過去の日付であるため)。
その年が将来の年である場合 (つまり、どちらも将来の日付である場合)、さらに奇妙になります。おおよその気まぐれのため、現在の日付から数か月後(年に関係なく) は反転しますが、それより前の日付は反転しません。このパッチは、このフォームの日付の「将来」チェックを削除し、将来
yyyy-mm-ddであっても常に として扱うようにします。このコード パスは、最初の数値が 70 より大きい場合 (つまり、年でなければならず、日付または月であってはならない) にのみ開始されるため、これ
は通常のルックアップとルックアップには影響しませんdd/mm/yyyy。mm/dd/yyyy考えられる犠牲者の 1 つは、"
yyyy-dd-mm" が " " よりも選ばれる可能性が低いことyyyy-mm-ddです。ただし、次の理由により、おそらく問題ありません。
- 違いは、日付が将来の場合にのみ発生します。すでに
yyyy-mm-dd過去の日付を優先しています。- 誰かが
yyyy-dd-mm定期的に使用しているかどうかは不明です。ウィキペディアの一般的な日付形式のリストには 表示されません。- (2) が間違っていたとしても、git の他の場所で使用しているものと一致しているため、ISO のような日付を好む方が良いでしょう。