已知的unixtime/epoch时间序列化格式有哪些？

Question

因此，纪元时间（又名“unixtime”）的“基本定义”及其含义是明确的。然而，在维基百科页面或我能找到的任何其他资源上，都没有提到纪元时间可以以各种同样现代的格式以不同程度的精度进行序列化。 （注意：我不是在询问 ISO 格式的日期/时间字符串及其变体。单独的主题。此外，我不是在谈论这些数字的低级编程表示，例如有符号整数与无符号整数、32 与64 位、闰秒与无等等。维基百科实际上涵盖了所有这些。只是 epoch/unix 时间的各种

序列化

，即在控制台中、在 JSON 中、在数据库中等） 例如，我偶然发现了至少 3 种基本变体：

1707882022 - 几秒钟内

• 1707882022000 - 以毫秒为单位，无小数点
• 1707882022.1598356 - 以微秒为单位，带小数指示器
例如，Javascript 默认为毫秒选项，而 Python 3 默认为微秒。这没什么大不了的，除了令人费解的决定（至少在 JS 中）在秒和毫秒之间表达没有小数点指示符的小数值。 （这有点打破了所有已知的 U/X 原则，因为我们都从一年级开始学习使用小数点。但我离题了。）

我的问题是：

这是所有可能的选项/格式吗？它们是在任何地方都定义/指定的，还是只是语言设计者的临时决定？

奖金将是以下问题的答案：这些都可以在所有主要编程语言上完全互操作吗？仅通过检测字符串/整数大小，所有等效的

new Date()

方法是否都同样好地支持所有三种格式？或者当多个语言环境共享一个公共数据存储时，某些地方是否需要进行手动转换？到目前为止，我还没有遇到任何故障，并且机器比我的眼睛更容易解析差异。我只是想知道是否有什么需要注意的...

Answer 1

1707882022

可能是 2024 年 2 月 14 日（秒），或 1970 年 1 月 20 日（毫秒）。没有系统可以检测哪个是正确的。您需要阅读相关系统的文档，它们有望告诉您是否使用秒或毫秒，以及它们是否使用浮点数或整数。如果有意义的话，其他系统也可以随意构成其他格式。您需要根据需要在格式之间进行转换，这主要意味着根据需要除或乘以 1000，并且可能转换为 float 或 int。