携带日期作为 Unix 纪元时间戳答案

【问题标题】：Carrying dates as the Unix Epoch timestamp携带日期作为 Unix 纪元时间戳
【发布时间】：2020-02-21 19:02:28
【问题描述】：

很久以前，我曾经在后端使用 Spring 处理特定项目。该系统应该跨多个时区工作。因此决定使用整数值 (Long) 在后端和 Web 应用程序之间存储和传输日期。我记得主要原因是为了简化和最小化时区的工作，因为时间戳总是代表准确的时间，我们总是能够从中检索 Date 而不必担心不正确的时区（用户的浏览器将应用正确的时区）。

那时我对建筑几乎没有兴趣，因为我只是一名大三学生。但是从那以后我就没有看到任何这种做法的应用，我在网上也找不到任何东西。

我知道在某些情况下我们不需要依赖时区，例如当我前往不同的国家/地区时，我不希望我的闹钟根据新时区更改。但我仍然希望我的提醒能够在我需要在正确的时间拨打重要电话时通知我。我相信第二种情况在软件中更为常见。

因此我想知道使用数字时间戳有什么真正的好处吗？

我看到了至少两个潜在的好处：

减少时区的麻烦（特别是对于经验不足的开发人员，他们有时会在处理日期时感到困惑）
通过 REST 传输的数据更少 (?)

缺点：

我们必须每次提取 Date 值来处理或显示它（这可以使用大多数前端框架自动完成）
数据库值和服务器调试并非不言自明

【问题讨论】：

标签： spring rest date time timestamp

【解决方案1】：

在数据库和高级语言中 DATE 类型的场景之下，总是有一些版本的相对日期偏移和分辨率。例如：

DOS 使用 1980 年 1 月 1 日，时间为 10 毫秒，
COBOL 假设为 1601 年 1 月 1 日，分辨率为 1 秒
UNIX 及其同类产品恰好选择了 1970 年 1 月 1 日午夜 GMT。

在数据存储中使用数字而不是解释数字的好处可以说是（但主观的）更容易的日期算术。对于依赖数字（与日期类型）作为数字本机的航空公司调度/物流等重度 TZ 的东西，尽管 TZ 以及政治上任意的 DST 调整，但无需日期类型函数转换即可保持一致性 .因为，Uniform Time Act 是距离统一最远的东西。

【讨论】：

【解决方案2】：

我会说这实际上取决于该值的指定用途。如果您期望技术用途，公开时间戳值可能更有意义，如果您期望任何其他用途，则公开时间戳值可能更有意义。ISO 8601。对于大多数用法，它们可能是同义词（注意闰秒）。它们都指的是一个固定的时间点。

将日期公开为 ISO 8601 字符串对于调试和人眼来说绝对更容易。你马上就知道，它是哪个时间点。

历史上，UNIX 时间戳也有一个缺陷，即受限于整数值的大小。在 64 位架构中，这通常不再是问题，但对于向后兼容，字符串将是更好的选择。

我绝对不建议在本地时区通过 API 公开日期。这样的值通常是模棱两可和不可靠的。它们对人类有好处，但对其他任何东西都没有好处。例如，考虑夏令时。有些时间段存在两次，有些时间根本不存在。

【讨论】：