Go 的時間格式化為什么是 2006-01-02 15:04:05？
大家好，我是 polarisxu。
沒有什么是完美的!而且，有些東西，有些人認為好，有些人認為很糟糕。Go 也是如此。喜歡 Go 語言的朋友，大概率對其中某些地方不喜歡。比如，你喜歡 Go 中時間格式化固定的 2006-01-02 15:04:05 -0700 嗎?為什么是這么一個時間?今天來一探究竟!
01 新手的困惑
無論是各種群里還是網上搜一下，包括國外的，對 2006-01-02 15:04:05 -0700 都很困惑。
一般的困擾主要有：
- 不知道只能固定要這個時間，換其他的，出來的結果莫名其妙，然后一臉懵逼;
- 為什么沒有像其他語言一樣，yyyy-mm-dd 這樣的形式?
- 這個時間有什么特殊意義嗎?為什么挑這么個時間，完全記不住;
這很正常，畢竟這一點上，Go 很另類，也可以說很“奇葩”。甚至有人注冊了一個域名：http://fuckinggodateformat.com/，我也是醉了。。。
但是這真的不好?
02 為什么這么設計?
為什么選擇這個時間?不少人有這樣的疑問。有人猜測是 Go 項目啟動的時間等。但仔細研究，發現 Go Team 還是用心良苦，目的是解決大家記憶問題。
比如常規的 ymd 格式，以 PHP 為例，一般這樣 Y-m-d H:i:s，輸出類似：2021-08-03 09:30:00，但如果我想輸出：21-8-4 9:30:00，你不查手冊，能寫出來嗎?你看看 PHP 文檔中關于 date 格式化的說明，頭有點大，竟然那么多，雖然常用的形式，大部分人都記得，但遇到不怎么常用的，就得查手冊了。
反觀 Go 語言，它直接使用一個具體的時間來當做格式化字符串，需要什么格式，改這個時間格式即可。比如上面的例子，常規方式：2006-01-02 15:04:05，而 21-8-4 9:30:00 這種格式，只需要對應的改變值即可：06-1-2 3:04:05。而且，我查了下，PHP 沒法表示沒有前導零的分鐘數和秒數，而 Go 很容易實現。很顯然，Go 的方式是更合理、更易用的，對于各種變化，也能夠更自如的應對。
只不過，很多人對這個具體的時間覺得記不住。這一點，Go 官方也考慮到了。畢竟采用特殊的時間，目的就是為了解決大家記憶問題，因此要確保這個特殊時間也好記。Go 是這么設計的：
- 1: month (January, Jan, 01, etc)
- 2: day
- 3: hour (15 is 3pm on a 24 hour clock)
- 4: minute
- 5: second
- 6: year (2006)
- 7: timezone (GMT-7 is MST)
剛好是 1 2 3 4 5 6 7，據此進行變化即可。
比如官方定義的常量：
- const (
- ANSIC = "Mon Jan _2 15:04:05 2006"
- UnixDate = "Mon Jan _2 15:04:05 MST 2006"
- RubyDate = "Mon Jan 02 15:04:05 -0700 2006"
- RFC822 = "02 Jan 06 15:04 MST"
- RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
- RFC850 = "Monday, 02-Jan-06 15:04:05 MST"
- RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
- RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
- RFC3339 = "2006-01-02T15:04:05Z07:00"
- RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
- Kitchen = "3:04PM"
- )
按 ANSIC 標準的日期格式，月、日、時、分、秒、年，最后加 MST 時區。對應就是 1 2 3 4 5 6 7。同時還可以隨意加星期幾。
發現沒有?圍繞著 1 2 3 4 5 6 7 隨意變化，真的不要太爽。我相信你用習慣了會發現 Go 這個設計真的太好了。
03 總結
Go 的設計原則之一：大道至簡。盡量簡介，讓大家開心編程。我認為這個格式化時間的設計也體現了這一點，他們設計的很用心。
知曉了為什么這么設計，我相信你看完這篇文章會從此愛上 Go 的時間格式化形式。
