go - Go 中的时间长度表示

Question

在 Unix 下，我正在开发一个程序，该程序需要根据时间是 32 位(将在 2038 年换行)还是 64 位而表现不同。

我认为 Go 时间并不神奇，它将在 2038 年包装在具有 32 位 time_t 的平台上。如果这是错误的并且它总是 64 位，请告诉我，因为这将避免太多的悲伤。

Go 中为平台的 time_t 大小编写测试的最简单方法是什么？有没有比 cgo 明显的 hack 更简单的方法？

Answer 1

如果你真的想找到time_t的大小，您可以使用 cgo 链接到 time.h .那么大小time_t将作为 C.sizeof_time_t 提供.它并没有变得更简单。

package main

// #include <time.h>
import "C"

import (
    "fmt"
)

func main() {
    fmt.Println(C.sizeof_time_t);
}

除了尝试将系统时间设置为越来越远的日期(这对该系统上运行的其他任何东西都不是很礼貌)之外，我不知道有什么方法可以在任何编程中以可移植方式直接查询硬件时钟的限制语。 C 只是硬编码 time_t 的大小在操作系统提供的文件中(在 OS X 上是 /usr/include/i386/_types.h )，因此您最好通过查询 time_t 的大小来利用该信息。来自 cgo .

但是这样做的理由很少。 Go 不使用 time_t并且似乎不会遇到 2038 问题，除非您确实计划在 2038 年让代码在 32 位机器上运行。如果这是您的计划，我建议您找到一个更好的计划。

I presume Go time is not magic and will wrap in 2038 on a platform with a 32-bit time_t. If this is false and it is somehow always 64-bit, clue me in because that will prevent much grief.

2038 年问题的大部分时间都是假设自 1970 年以来的时间将适合 32 位有符号整数的程序。这会影响时间和日期函数，以及自 1970 年以来选择将时间表示为 32 位有符号整数的网络和数据格式。这不是一些硬件限制(除非它实际上是 2038，见下文)，而是一种设计旧编程语言和协议(protocol)的限制。没有什么能阻止您使用 64 位整数来表示时间，或选择不同的时代。这正是较新的编程语言所做的，不需要魔法。

在 Unicode、并发性和 32 位时间(即 Year 2038 Problem)等问题被认为是任何编程语言都必须解决的问题之后很久，Go 于 2009 年首次发布。鉴于 C 的时间库存在很多问题，我非常怀疑 Go 是否在使用它。 A quick skim of the source code confirms .

虽然我在 Go 文档中找不到任何明确提及其限制的 Time表示，它似乎与 C 的 time.h 完全脱节结构如 time_t .自 Time使用 64 位整数，除非您要求实际时钟时间，否则似乎没有 2038 个问题。

深挖 the Go docs for Time 我们发现它们的 0 远远超出了 32 位的范围 time_t范围从 1901 年到 2038 年。

The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC

time.Unix 将秒和纳秒作为 64 位整数，这无疑与 time_t 的大小无关。 .

time.Parse 将解析“在 0000..9999 范围内”的一年，再次远远超出 32 位 time_t 的范围.

等等。我能找到的唯一限制是 Duration被限制为 290 年，因为它具有纳秒精度，而 290 年大约是 63 位的纳秒。

当然，您应该在具有 32 位 time_t 的机器上测试您的代码。 .

2038 问题的一个侧面问题是时区。计算机从时区数据库中计算时区信息，通常是 the IANA time zone database .这允许人们在某个时间获得某个位置的时间偏移。

计算机安装了自己的时区数据库副本。不幸的是，很难知道它们的位置或它们上次更新的时间。为避免此问题，大多数编程语言都提供自己的时区数据库副本。 Go does as well .

具有 32 位时间的机器的唯一真正限制是其硬件时钟的限制。这告诉软件现在是什么时间。如果您的程序在 2038 年仍在 32 位机器上运行，则 32 位时钟只会成为一个问题。缓解这一问题没有多大意义，因为 一切在那台机器上也会有同样的问题，他们不太可能将其考虑在内。您最好在 2038 年之前停用该硬件。