为什么 kdb+ 纪元日期是 2000.01.01？

Question

我是 kdb+ 的新手，我想知道为什么 kdb 的纪元日期 2000.01.01 与 unix 的纪元日期 (1970.01.01) 不同。

这种差异是否会影响与操作系统或其他语言的任何交互？

Answer 1

KDB+ 使用不同的纪元，因为它遵循不同的标准。 KDB+遵循基于儒略年的J2000国际标准。

UNIX 使用 POSIX 时间，它最初是一个 32 位无符号整数。因为时间计算到60秒，32位整数只能工作829天左右，所以必须选择最近的日期。

1971 年 11 月 3 日的第一版 Unix 程序员手册将 Unix 时间定义为 "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second"

如果您在将所选纪元时间传送到应用程序之前没有确保转换为一个标准，这种差异可能会导致问题。

Answer 2

关于与 system/other 语言交互的问题应该能够通过 KDB 可以解析 UNIX 纪元时间戳这一事实得到解决

来自 http://code.kx.com/q/ref/casting/#tok

Parsing Unix timestamps (from seconds since Unix epoch), string with 9…11 digits:
q)"P"$"10129708800"
2290.12.31D00:00:00.000000000
q)"P"$"00000000000"
1970.01.01D00:00:00.000000000

Answer 3

Kdb+ 在许多不同的操作系统上可用，目前 Windows、Linux-x86、Linux-ARM 和 OSX 可从 [= 下载11=]，以前的 solaris 可用。

从维基百科上关于 system time 的页面我们可以看到，不同的操作系统使用不同的纪元日期和范围。考虑到 kdb+ 支持的两个 OS 我们可以看到它们具有不同的纪元范围：

OS              Epoch or range
-------------------------------------------------
Unix/Posix      1 January 1970 to 19 January 2038
Windows         1 January 1601 to AD 30,828

使用 linux 或 windows 纪元将意味着另一个不匹配。对该页面的进一步阅读还表明，许多其他语言也使用自己独特的纪元日期和范围。

简而言之，一种语言没有理由需要使用它运行所在的 OS 的纪元时间。

为什么 kdb+ 纪元日期是 2000.01.01？

Why is the kdb+ epoch date 2000.01.01?

kdb

q-lang