Goの日時書式の話

はじめに

こんにちは。マーケティングオートメーションツール「ListFinder」開発チームのはちです。
普段はデータ加工や外部システムとのデータ連携処理などをGo言語で書いています。

今回は社内LTで発表した Goの日時書式の話 についてです。

この記事は、以下のスライドの内容を元に行った発表の内容を再構成したものです

Goの日時書式って特殊ですよね

みなさん、Goの日時書式はご存知ですか？こんなやつです。

package main

import (
	"fmt"
	"time"
)

func main() {
	fmt.Println(time.Now().Format("2006-01-02 15:04:05")) // Format()メソッドの引数に書いてある文字列です
}

実際の日時に見えてしまって全く直感的ではありませんね。
他の言語では yyyy-mm-dd など、人間が直感的に理解しやすい日時書式を採用していることが多いです。
人間にとって直感的ではない特殊な形式を採用していることで、Goの日時書式はSNSで批判を浴びがちです。
でも、Goの日時書式は実はよく考えられていて一度ルールを覚えたら使いやすいんです。

こうなっている理由はちゃんとある

Goの日時書式はアメリカの慣例に基づいています。
アメリカの慣例では日時の表記は 月 日 時:分:秒 年 の順番です。実際の例を出すと Jan 1st 12:34:56 2007 などです。

このルールに基づいた並びで先頭から1,2,3... と番号をつけています。
分かりやすいようにか知りませんが、年は4桁で 2006 で固定、 分は12時間表記なら 3 で24時間表記なら 15 です。

ただし年月日の並び順の方が世界的に広く使われている

ですが、世界的に 年月日 の並び順の方が広く使われています。
ISOにも日時フォーマットでその並び順が採用されています。
それにも関わらずなぜこの並び順になったのか。
それは、Go言語開発者の Rob Pike がそのことを知らなかったからです。
後にGoのメーリングリストでこの仕様は間違いだったと語ったそうです。
では言語仕様を変更して使いやすくすればいいじゃん、と思いますよね。
ですが、後方互換維持のためGo1.xの間はこのままです。

アルファベットで表す形式の方が他の言語には多い

他の言語ではアルファベットで表す、人間が直感的に意味を理解しやすい形式を採用しています。いくつか例を挙げるとこんな感じです。

• PHP: Y-m-d H:i:s
• MySQL: %Y-%m-%d %H:%i:%s
• C: %Y-%m-%d %H:%M:%S
• PostgreSQL: YYYY-MM-DD HH24:MI:SS
• JavaScript: YYYY-MM-DD HH:mm:ss
• SQLServer: yyyy-MM-dd HH:mm:ss

同じような書式が多いので経験が増えるほど迷う

直感的に意味が理解しやすい形式ではあるのですが、それぞれ微妙な違いがあるため経験を積むほど迷うようになります。
年が4文字？1文字？？ % はつけるんだっけ？？？大文字小文字どっちだっけ？？？？ と。
で、最初に迷ったところで答えが出ずに諦めてリファレンスを見ることになります。
言語ごとに覚えておけば良いと言えばそうなんですが、それほど使う頻度が高いわけでもないので忘れちゃうんですよね。あと丸暗記で覚えるのは良くありません。
よく使われる設計だから使いやすいかというとそういうわけではなく、同じような設計が増えると微妙な違いが増えて迷いやすくなります。

Goの日時書式はルールを覚えれば迷わない

Goの日時書式はパッと見では意味不明ですが、ルールを覚えれば迷わずたどり着けます。

1. 数字を並べればOK
2. 月日時分秒年の順で1から6まで
3. 時分秒をゼロ埋めするなら0をつけて2桁にする
4. 年は4桁で2006固定でOK
5. 時は24時間表示なら午後3時の15

ユニークかつルールが明確なので、ルールを覚えれば迷うことはありません。
万が一このような形式を採用する言語が増えてしまったら微妙な差が出てきてしまい迷うことになると思うので今だから言えることですが。

それと、標準パッケージに日時書式の定数が色々定義されていまして、Go1.20からよく使われる yyyy-mm-dd hh:MM:ss 形式も time.DateTime と書けば良くなったので日々使いやすくはなってきています。

まとめ

ということで、今回のまとめです。

• Goの日時書式は一見変だけどちゃんと考えられているよ
• よく使われるパターンは似たパターンが多いとむしろわかりづらくなる
• 見慣れないからといって拒絶するのではなくなぜそうなのか調べると良い
• 一貫した設計思想に基づいて実装ルールを徹底するのは認知負荷を下げる

以上になります。