共计 1427 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我是煎鱼。
前段时间我写了一篇《Go1.20 中两个对于 Time 的更新，终于不必背 2006-01-02 15:04:05 了！》，文中有提到 Go 的参考工夫格局是：2006-01-02 15:04:05，并解释这么设计的原因。
有很多同学示意不解。如下图：
甚至我在点外卖时还特意看了，某团在个人信息页中的生日那一栏，是如此显示的：
那相熟的 yyyy-mm-dd。我甚至一度狐疑这是不是 BUG，这可能只有程序员懂？
ISO 8601 标准
尤其是有提到 ISO 8601，这是一个国际标准化组织提供的一个无关工夫示意的标准，其中咱们最为相熟的是日期表示法。
具体介绍摘抄自网络，如下：
YYYY-MM-DDThh:mm:ss[.mmm]TZD
2022-11-18T10:05:45+08:00- YYYY：四位数年份，不全补齐。
- MM：月份、两位，不全补齐。
- DD：两位数的天 (day of the month)，01~31。
- T：批示工夫元素的开始字符。
- hh：两位数的小时，00~23。
- mm：两位数的分钟，00~59。
- ss：两位数的秒，00~59。
- mmm：三位数的毫秒，000~999。
- TZD：时区批示符：Z 或 +hh:mm 或 -hh:mm，+ 或 – 示意时区间隔 UTC 时区多久。
为什么这么特地
咱们之前的文章都在介绍 2006-01-02 15:04:05 这个工夫点代表的含意是什么，代表什么意思：
Jan 2 15:04:05 2006 MST
1 2 3 4 5 6 -7这有一个大大的问题，那就是 Go 为什么不恪守 ISO 8601 标准，非得用这个？这莫非是一种新的翻新 …
在我猛翻后，找到了在对标准化辩解的背地。实际上 @Rob Pike 在 2014 年在《What is the reason behind time.Parse using a reference time?》进行了解释，阐明为什么会抉择这个工夫点。
“ 这个抉择是由我的 Unix 机器上的 date 命令的输入所决定的 。我应该意识到格局会随着地区的不同而变动。错了。但我依然能够说它很容易记住，并且有据可查。”
这就是起因。
为什么那么好受
大家一开始可能认为只有咱们用的比拟变扭？但其实不止，各地的人都拥到了社区里反馈过这个问题。
归根到底还是世界各地用的工夫格局不一样，而 Go 这里依据 Rob 的反馈，实际上它只是以某国为工夫核心的“随机”格局，对应的就是“1 2 3 4 5 6 7”。
例如：“Jan 2 3:04 pm 06 -0700”。
所代表的意义：
- Jan：第一个月
- 2：第二天
- 3：下午 3 点
- 4：第 4 分钟
- 5：第 5 秒
- 6：本世纪第 6 年
- 7：比格林威治规范工夫晚 7 小时。
看起来很有法则，但 …
总结
Go 的这一项工夫标准抉择，是比拟非凡的。很多同学心愿他“弃暗投明”，用回 YYYY-MM-DD，别再用 2006-01-02 15:04:05 了。
这显然不事实，首先是 Go1 兼容性不容许，其次一山不能容二虎，加预计都没法加。这件事已成定局。
倡议还是记好 Go1.20 要新增的 3 个常量，这个当前不必去背和查了。如下：
DateTime = "2006-01-02 15:04:05"
DateOnly = "2006-01-02"
TimeOnly = "15:04:05"这个比拟事实。
这个设计，我认为是技术债权了。将会继续陪伴 Go1 一生，你我皆为局中人。
Go2 有戏吗？暂未看到。
举荐浏览
- Go1.20 中两个对于 Time 的更新，终于不必背 2006-01-02 15:04:05 了！
- 打脸了兄弟们，Go1.20 arena 来了！
- Go 十年了，终于想起要对立 log 库了！
