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

一般来说，最好的做法是用 UTC 存储时间，如中所述here and here.

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

方法一：如果决定的话以 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 当地时间，如果在 2012 年 10 月 10 日转换（时区 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 存储时间仍然是一个好主意吗？如果是，那么如何获得恒定的本地时间？

相关问题：是否有充分的理由不使用 UTC 存储时间？

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

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

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

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

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

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

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

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