大家好，我是 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 的时间格式化形式。
