date - 以 UTC 存储时间总是一个好主意，还是在这种情况下以本地时间存储更好？

Question

通常，最好的做法是以 UTC 格式存储时间，如 here 中所述。和 here .

假设有一个重复发生的事件，假设结束时间始终为同一本地时间(假设为 17:00)，无论该时区是否启用夏令时。并且还要求在特定时区的 DST 打开或关闭时不要手动更改时间。还有一项要求是，每当任何其他系统通过 API(即 GetEndTimeByEvent)询问结束时间时，它始终以 UTC 格式发送结束时间。

方法 1:如果决定以 UTC 存储，则可以将其存储在数据库表中，如下所示。

Event      UTCEndTime
=====================
ABC         07:00:00
MNO         06:00:00
PQR         04:00:00

对于第一个事件 ABC，UTC 结束时间为上午 07:00，如果将 2012 年 7 月 1 日的 UTC 时间转换为本地时间，则结果为本地时间 17:00；如果在 10 月 10 日转换，则结果为本地时间 17:00 -2012(该时区 DST 开启的日期)将导致下午 6 点，这不是正确的结束时间。

我想到的一种可能的方法是将 DST 时间存储在附加列中，并在时区启用 DST 时使用该时间。

方法 2:但是，如果存储为本地时间(如下所示，对于事件 ABC)，则任何日期都将始终为 17:00，因为没有从 UTC 转换为本地时间。

Event      LocalEndTime
=======================
ABC         17:00:00
MNO         16:00:00
PQR         14:00:00

应用层将本地时间转换为UTC时间，通过(API GetEndTimeByEvent)发送到其他系统。

在这种情况下，以 UTC 格式存储时间仍然是一个好主意吗？如果是，那么如何获得恒定的本地时间？

相关问题:Is there ever a good reason to store time not in UTC?

Answer 1

我认为为了回答这个问题，我们应该考虑使用 UTC 存储时间戳的好处。

我个人认为这样做的主要好处是时间总是(大部分)保证一致。换句话说，每当更改时区或应用 DST 时，您都不会及时返回或返回。这在文件系统、日志等中特别有用。但这在您的应用程序中是必要吗？

想想两件事。首先，关于夏令时时钟移位的时间。您的事件有可能发生在凌晨 2 点到 3 点之间(时钟调整结束当天)吗？那么会发生什么？

其次，应用程序是否会受到实际时区变化的影响？换句话说，您打算乘坐它从伦敦飞往华沙，并适当更改您的计算机时区吗？在这种情况下会发生什么？

如果您对这两个问题的回答都否，那么您最好使用本地时间。这将使您的申请更加简单。但如果您至少回答一次是，那么我认为您应该多思考一下。

<小时/>

这就是关于数据库的全部内容。另一件事是应用程序内部使用的时间格式，这应该取决于您实际上将用该时间做什么。

您提到它通过 API 公开时间。应用程序是否会在每次请求时都会查询数据库？如果您在内部将时间存储为 UTC，则您需要这样做，或者以其他方式确保在 DST/时区更改时，缓存的时间将得到调整/修剪。

它会对时间本身产生什么影响吗？比如打印事件将在 8 小时内发生，或者在大约那时暂停？如果是的话，那么 UTC 可能会更好。当然，你需要考虑到上述所有问题。