是否有充分的理由不以 UTC 存储时间？答案

【问题标题】：Is there ever a good reason to store time not in UTC?是否有充分的理由不以 UTC 存储时间？
【发布时间】：2010-11-10 19:08:11
【问题描述】：

我想知道是否有任何充分的理由将时间信息存储在 UTC (GMT) 以外的任何地方？我相信这是所有软件工程的可靠规则。转换为本地时间只是为了显示目的而在 UI 层发生的转换。我还看到了需要翻译才能正确实现算法（用于处理午夜日期更改等）的情况。

【问题讨论】：

标签： date time utc

【解决方案1】：

我会说它依赖于应用程序。我研究电离层和磁层的空间物理模型。我们使用磁性当地时间，将日期和时间存储为Modified Julian Days。

【讨论】：

【解决方案2】：

当您确定只使用当地时间时。

【讨论】：

【解决方案3】：

警报和计划任务有时会以当地时间存储，因此它们不会受到夏令时或时区更改的影响。

【讨论】：

它们是/stored/ 在当地时间还是更好的方法是获取 UTC 并拥有一个 convertToLocalTime() 成员函数？
@Pete：想想我的闹钟：闹钟设置为当地时间早上 7 点。当时钟在冬天回来时，我不想在早上 6 点被吵醒。当我到西部出差时，我不想因为回家的时间是早上 7 点就在半夜被吵醒。
@Dave 是的，所以您只需更改 TIME_ZONE += n，因此 convertToLocalTime(currentUtc, TIME_ZONE, isDaylightSavingsTime) 将返回本地时间（即使它在内部存储为 UTC）。
你可以做所有这些，但为什么呢？它不会给你带来任何好处。
因此，为了存储没有任何特定关联日期的时间，使用本地时间是有意义的。好点。

【解决方案4】：

曾经？我确信在一些孤立的情况下有充分的理由。不过，一般来说，存储 UTC 比本地时间好得多，所以除非有特殊考虑，否则我会将 UTC 视为默认位置。

【讨论】：

【解决方案5】：

总的来说，我发现使用 UTC 会更好。有时您可能需要当地时间。那我宁愿选择 UTC + 时区信息。

通常情况下，重复事件非常棘手，您应该非常仔细地分析用例。

想象一个定期会议，每周二上午 9:00。如果 DST 更改，会议仍应在（新的）上午 9:00 举行。

但是法国的一些人没有加入会议。对他们来说，会议时间是下午 6:00。他们通过不同的规则更改 DST。

当您更改 DST 时，他们不会，因此在一段时间内（直到法国更改 DST）有人应该“关闭”：您的会议将在上午 10 点举行，而他们的会议将在下午 6 点举行，或者您的会议将在上午 9 点举行并在下午 5 点搬家。没有别的办法，电脑与它无关。

应用程序将如何决定应该“修复”谁？是成员最多的组吗？（美国有 1 个人，法国有 20 个人？）或者是关于人的重要性？（如果美国的 1 个人是 CEO 怎么办？）

你如何存储这些信息？我最好的解决方案是使用 UTC + 一个“主时区” “主时区”中的用户获胜（保持不变）。

事情可能会变得相当棘手，但总的来说，我发现 UTC 解决的问题比它引入的要多。

澄清fjsj 的一个（非常有效的:-) 点：“主时区”是指确切的时区，包括有关 DST 是否有效的信息。

如果只存储PT（太平洋时间），那是不够的。 PST（太平洋标准时间）或PDT（太平洋夏令时间）。

最好不要将重复会议视为“固定时间点”，以“时代”的秒/毫秒表示。编程语言（终于）开始采用 JodaTime 的概念。

【讨论】：

如果我错了请纠正我，但我认为存储 UTC + 主时区并不能解决 DST 更改的问题。实际示例： 1 - 您需要存储日期时间“从现在起一年后的纽约时间上午 9 点”。您计算这是否为 UTC 并将其与纽约时区一起存储在您的数据库中。 2 - 在 1 年过去之前，纽约将其更改为 DST。纽约时间上午 9 点的原始日期与我们存储的日期不同。
4 年后，对不起！但我认为 PST/PDT 信息对未来事件无效，因为 PST 成为 PDT 的日期，反之亦然，将来可能会发生变化。我不知道它是如何专门为美国太平洋时间工作的，但在某些时区，夏令时的开始每年都会发生变化。对于未来的活动，您真正需要的是保存“9am at America/Los Angeles”。无论洛杉矶处于 PST 和 PDT 中，这都将起作用。见：creativedeletion.com/2015/03/19/…

【解决方案6】：

在嵌入式系统中，您很可能会以某种“过去纪元”的形式从源接收时间。

如果时间更新比较频繁，显示的频率比较低，那么您不妨以提供给您的相同方式存储它，只在需要时将其转换为显示。

不过，一般来说，除非有其他考虑，否则 UTC 是可行的方法。

【讨论】：

【解决方案7】：

UTC 是一种计时标准，具有TAI 的准确度和精确度，但添加了不规则间隔的闰秒，使其能够密切跟踪平均太阳时 (UT1)。

如果您使用的系统无法处理闰秒，那么Bureau International des Poids et Mesures 建议使用 TAI 而不是 UTC。

【讨论】：

现在你需要更多的支持，我不明白为什么人们认为 posix 时间每隔几年就会倒退一次是线性的
Pacerier：它倒退了？哎呀。我没有意识到这一点。我以为它只是由于地球自转缓慢而向前跳跃。
它在历史上实际上从未飞跃过（未来可能），但平均每 1.5 年后退一次。如果我们有一个每半秒分裂一次的秒表，时间是这样的：58.0 58.5 59.0 59.5 00.0 00.5 00.0 00.5 01.0en.wikipedia.org/wiki/Unix_time