长话短说，我们开发了一个供内部使用的网络应用程序，有一件事导致了另一个，现在它是一个拥有超过1,000个用户的SaaS。问题是所有与日期相关的事情（很多！）都是硬编码到太平洋时间（不要问），用户显然想要自己的时区。
我已经了解了管理网络应用中时区的最佳方式，但仍然不确定使用我们现有的，实时关键网络应用程序的最佳方式，超过1,000家企业使用... < / p>
我猜这个大问题＆＃34;只是我们谈论的是100k +代码行，可能至少有100个与日期相关的DB查询。
从我所读过的内容来看，它似乎是正确的＆＃34;管理时区的方法是以UTC格式存储所有内容，然后在输出时转换为用户TZ ...
但是在这一点上，简单地修改所有与日期相关的查询并基本上用MySQL的convert_tz包装所有日期以将现有的PDT时间戳转换为用户的时区会有什么问题吗？
据我所知，如果我们将数据库中的所有日期字段转换为UTC并将MySQL更改为在UTC下运行，我们无论如何都要做同样的事情，所以有什么特别的理由来转换所有此时现有的日期字段是否为UTC？
答案 0 :(得分：1)
嗯，“正确”很大程度上取决于您的应用程序的功能，以及应用程序中的日期。在许多情况下，存储为UTC并转换为用户的时区正是所需要的。但不是全部。
例如，如果您的日期是用于安排未来事件的重复模式的一部分，那么您将不会使用UTC。
另一个例子是，如果您有仅限日期的字段，那么这些日期可能是“工作日”，可能基于用户的时区，但可能基于您的业务时区。
存储为UTC的最常见情况是指您指的是一个明确的时刻，例如存储实际发生的事件的时间戳（过去时）。
回到你的问题 - 为什么不把它放在太平洋时间？太平洋时间不像UTC那样固定。它在PST的冬天是UTC-8，在PDT的夏天是UTC-7。因此，每年都会有一小时的缺口，缺少当地时间，而且当地时间重复时会有一小时的重叠。您可以在the daylight saving time tag wiki中了解详情。
我建议你采取以下方法：
1:00:00.000和1:59:59.999之间。您可能需要手动调整这些值，因为它们可能属于PDT或PST。要消除歧义，请查看是否还有其他值要考虑。例如，如果您有一个自动递增的主键，那么当按该键排序时，时间戳应大致是顺序的。