乐趣区

关于后端:Go-凭什么搞特殊不用-yyyymmdd非得要-20060102-150405

大家好,我是煎鱼。

前段时间我写了一篇《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 库了!
退出移动版