这几种时间戳函数的安全性及整数溢出问题

目前golang学习网上已经有很多关于Golang的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《这几种时间戳函数的安全性及整数溢出问题》，也希望能帮助到大家，如果阅读完后真的对你学习Golang有帮助，欢迎动动手指，评论留言并分享~

我在这里读到 https://pkg.go.dev/time#unix unix() 返回 自 1970 年 1 月 1 日以来给定 unix 时间、秒秒和纳秒纳秒对应的本地时间 utc

您还可以分别使用 unixnano() 和 unixmilli() 获取自 1970 年以来的毫秒数或纳秒数。

我想我对这如何安全感到困惑。当纳秒、毫秒或常规秒数超过 int64 的容量时，是否会出现日期/时间中断？

此外，我正在通过打印 time.now.unix() 来尝试 go 演示 https://go.dev/play/，我总是会得到 1257894000 秒，即使我运行代码的时间间隔大约一分钟.

但是，如果我这样做，我确实看到了差异

time.Now.Unix()
time.Sleep(time.Duration(1) * time.Second)
time.Now.Unix()

这给了我 1257894000 和 1257894001。

我对 unix 时间的基本工作原理感到困惑。

正确答案

Time.Unix()、Time.UnixMicro()、Time.UnixMilli()、Time.UnixNano() 均返回带符号的 int64。

最大有符号 int64 为 9,223,372,036,854,775,807

这意味着 Time.Unix() 在2920 亿年内都不会用完整数。毫无疑问，它会比人类更长寿。

最坏的情况是 Time.UnixNano() ，它将在 2262 年 4 月 11 日星期五 11:47:16.854 PM GMT 上用完 的整数。我不了解你，但我会死，希望没有人会使用我的代码。

好了，本文到此结束，带大家了解了《这几种时间戳函数的安全性及整数溢出问题》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！