仅在日期和时间上进行时区转换 - 有必要吗？答案

【问题标题】：Timzone conversions on date only and time only - is it necessary?仅在日期和时间上进行时区转换 - 有必要吗？
【发布时间】：2011-05-06 23:11:11
【问题描述】：

我们一直致力于为我们的 Web 应用实现时区支持。

我们已经在 MYSQL 中实现了 OLSON TZ 数据库，并将其用于 TZ 转换。

我们正在构建一个日程安排应用程序，因此：

我们将在 UTC 时间的特定日期和特定时间发生的所有预订存储在 DateTime 字段中，并使用 CONVERT_TZ() 进行转换。这很好用。

我们不太确定的是假期和休息之类的东西：

假期只是日期参考，不包括时间部分。因为CONVERT_TZ() 不适用于日期对象，我们猜测我们最好只根据用户的时区存储日期值？

id1 id3 startDate   endDate
-----------------------------
3   6   2010-12-25  2011-01-03
4   3   2010-09-22  2010-09-26

一周中的每一天存储期间的重复中断也是如此。我们目前为一周中的每一天存储索引为 0-6 的休息时间。因为这些只是时间对象，我们不能使用 CONVERT_TZ() 并假设我们应该将它们作为时间值存储在用户的时区中？

bID sID dayID startTime  endTime
--------------------------------
1   4   1   12:00:00    14:00:00
2   4   4   13:30:00    13:30:00

在这种情况下，对于假期和休息，我们只会在预订时间转换为用户的本地时间之后将它们与预订时间进行比较。

这是处理事情的正确方法，还是我们应该以其他方式存储假期和休息时间，以便我们可以将它们转换为 UTC（不确定这对于休息时间如何工作）。

感谢您的帮助！

【问题讨论】：

【解决方案1】：

我不太了解您的问题，无法说我的回答对您来说是 100% 正确的。但我认为您需要做的是将 DateTime 存储在“本地”时间并存储时区。这样，即使夏令时发生变化（发生这种情况），您也可以正确处理。

【讨论】：

您好，感谢您的帖子。我有点困惑，因为您使用偏移量保存在本地的建议与我读过的大多数其他文章背道而驰。根据我的理解，通过在 MYSQL 中使用 Olson 数据库并在 UTC 中保存并在检索时使用 TZ_CONVERT 我们解决了对 DST 开始/结束日期进行任何更改的问题：stackoverflow.com/questions/2532729/…、stackoverflow.com/questions/2532729/…、stackoverflow.com/questions/11975/handling-timezones-in-storage
是的，我知道每个人都说使用 UTC 并转换。另一方面，我也不断看到软件的故事，包括 Outlook 和 iPhone，在 DST 更改时出现问题。我们从来没有遇到过这种方法的问题。

【解决方案2】：

这两种存储格式看起来不错。您只需将它们从表格中拉出时转换为用户的本地时间。

实际上，对于休息时间表，我假设它们名义上已经是当地时间，所以您只需直接与约会的当地时间进行比较即可。

【讨论】：