コミットの日付を編集しようとしたら、Author Dateが4か月先になっていた件について

去る日は2024年6月10日のこと。

「さて、長いブランチをrebase -iしたから、日付も今日に合わせておくか。」

男には、自身の作業ブランチを`rebase i`で1コミットに纏める癖があった。
特に、タスクのウェイトが重かったりしてコミットログが汚れている場合には、この作業をすることがそれなりに楽しみでもあった。

しかし、`rebase -i`をしただけでは、後にログを見た時の日付（Author Date）が、幹のブランチから分岐した後の最初のコミットの日付になってしまい、少し不自然になってしまうのだ。
何より細かいところにこだわる彼にとっては、これは非常に大事な作業であった。

```bash:Git Bash
#git rebase -i .....

git commit --amend --date "`date`"
> [detached HEAD .......] MSG...
>  Date: Sun Oct 6 10:14:08 2024 +0900
```

男「ん？なんか日付がOctopa🐙...October、10月になってね？？？」

不審に思った男が調べてみると、なんと信じがたいことに、過去、同様に`rebase -i`と`git commit --amend --date`でまとめてマージしたすべてのコミットの日付が3,4か月ほどずれているではないか。

男「なん...だｔ......」

男はあまりのショックに息絶えてしまった。

## なんで

めっちゃ人類の作ったものに詳しい機械系の友人C君に聞いてみると、`--date`オプションに渡しているdateがおかしいのでしょうとのこと。
提案された`date -Iseconds`を使ってみると確かに形式が違う。

Gitが求めている形式はISO 8601形式というものらしい。

```bash:Git Bash
date
> Mon Jun 10 10:13:09     2024

date -Iseconds
> 2024-06-10T10:18:42+09:00
```

-Iseconds形式を使って再設定すると、確かに、正しく今日の日付で設定されている。

```bash:Git Bash
git commit --amend --date="$(date -Iseconds)"
> [detached HEAD .......] MSG...
>  Date: Mon Jun 10 10:14:49 2024 +0900
```

しかし、何故このようなことが起きるのか。
C君に聞くと、「フォーマットによって『Jun 10』を『6日 10月』だと思ったかも？」とのこと。

んなわけ...あるの？

試しに手近なJSで試してみたけど、正常に読み込んでいる。

```js
new Date("Mon Jun 10 10:13:09     2024")
> Mon Jun 10 2024 10:13:09 GMT+0900 (日本標準時)
```

コマンドのHelpだとたいそうなことは載っていなかったので、Gitの公式を見てみる。
~~ダウンロードの用以外で来たの初めて~~

>https://www.git-scm.com/docs/git-commit#_date_formats
>
> DATE FORMATS
> The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables support the following date formats:
>
> Git internal format
> It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp> is the number of seconds since the UNIX epoch. <time-zone-offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.
>
> RFC 2822
> The standard date format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.
>
> ISO 8601
> Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well. Fractional parts of a second will be ignored, for example 2005-04-07T22:13:13.019 will be treated as 2005-04-07T22:13:13.
>
> Note
> In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
> In addition to recognizing all date formats above, the --date option will also try to make sense of other, more human-centric date formats, such as relative dates like "yesterday" or "last Friday at noon".

雑な翻訳版

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/990851/589200be-c80e-33d5-5447-7fd7dd9905c5.png)


原因は分からなかったけどこの、いろいろな形式を解析してるニュアンスが怪しいっぽい。

関係ないかもしれないけど一番怪しいところ
> 上記のすべての日付形式を認識することに加えて、この--dateオプションは、「昨日」や「先週の金曜日の正午」などの相対的な日付など、他のより人間中心の日付形式も理解しようとします。

いやまじかよ。

試してみると、

```bash:Git Bash
#Majikayo
git commit --amend --date="yesterday"
>Date: Sun Jun 9 10:46:32 2024 +0900

#Iya,Majika
git commit --amend --date="today"
fatal: invalid date format: today

#Korede,Eeyan
git commit --amend --date="now"
Date: Mon Jun 10 10:49:37 2024 +0900
```

yesterdayがあるのにtodayがないの、割と訳わからん。
ジョークプログラム的なやつなんだろうか。

男「原因は分かんなかったけど、収穫はあったか、これからは`--date="now"`にしよ。」
男は、自分がまた世に１つ、「調べましたが分かりませんでした」系記事を生み出してしまったことには、特に、気づいてはいないようだった。

～終～