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

Question

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

score 25 · Accepted Answer

一般来说，我发现使用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 的概念。

score 12 · Accepted Answer

我会说它取决于应用程序。我研究电离层和磁层的空间物理模型。我们使用磁性当地时间，将日期和时间存储为修改后的儒略日。

score 8 · Accepted Answer

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

score 5 · Accepted Answer

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

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

在嵌入式系统中，您很可能会以某种“滴答作响”的形式从源接收时间。

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

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

score 0 · Accepted Answer

0

当您确定将仅使用本地时间时。

于 2009-07-14T20:26:39.043 回答

7 回答 7