php - 关于在 mysql 数据库中存储 PHP 支持的时区的最佳实践

Question

我想知道存储 PHP 的 'supported timezones' 的最佳实践是什么是。我正在存储每个用户的时区，这样我就可以将 UTC 时间转换为他们的本地时间。你会把它作为字符串存储在 varchar 类型的字段中吗？在这种情况下，最长可能支持的时区字符串是多少？有没有更好的做法来存储这些？简单地存储时区偏移量不是一种选择，因为它不会像 PHP 的日期时间对象那样自动考虑 DST。

Answer 1

这几乎与这个问题完全相同: Proper way to store a timezone in a database?

但我将解决您提到的其他几点:

• PHP 时区是 IANA time zones .

• 只需将名称存储在 varchar 中。有讨论here关于时区名称的字段长度。 varchar(32) 可以工作，但为了安全起见，我会为将来的更改留出一些额外的空间。 255 可能有点矫枉过正，但也许 varchar(50) 是合理的。

• 很多人建议将 UTC 存储在数据库中。这有时是一个很好的做法，但我不喜欢它被推荐为你应该总是做的事情。有充分的理由使用 UTC，也有充分的理由使用本地时间。

• 如果您使用 UTC，您将需要时区名称，并且必须在输入和输出时与本地时间相互转换。

• 如果您使用本地时间，除了本地时间之外，您应该始终存储时区偏移量。这是因为在 DST 转换期间本地时间可能不明确。一些数据库有一个专门用于此的类型，例如 Oracle 或 Postgres 中的 TIMESTAMP WITH TIMEZONE 或 SQL Sever 中的 DATETIMEOFFSET。不幸的是，MySql 没有用于此的类型，因此您将需要两列。

• 如果您的数据只记录一次并且永远不会更改(例如记录的事件时间)，那么这些选项中的任何一个都是可行的。 UTC 具有为数学和转换做好准备的优势。本地时间的优点是可以保留观察者的视角。参见 DateTime vs DateTimeOffset这是关于 .Net 的，但概念在这里仍然适用。

• 如果您要编辑这些时间，那么无论哪种方式，您都需要时区名称，因此最好将其存储起来。您可以决定是按记录的时间戳存储它还是每个用户只存储一次。您应该考虑如果用户更改他们的时区您希望发生什么。它应该适用于所有地方吗？还是只针对新记录的条目？

我可以想到一些不存储为 UTC 的实际原因:

• 如果您运行的报告将输出成百上千行，并且所需输出是记录的本地时间，则必须在紧密循环中多次从 UTC 转换 可能会减慢报告的执行时间。

• 有时，法律要求准确存储显示的时间。非技术审计员可能不允许任何类型的转换，并且会认为 UTC 时间是非法的。如果他们查看本地时间加偏移值，他们可能不会关心偏移部分，并且会对本地时间值感到满意。我知道这看起来很愚蠢，但确实存在这些要求的行业和司法管辖区。

• 有时您并不想真正指代某个时间点，而是具体指那个时间的本地化表示。假设您在美国各地的餐厅都在早上 6:00 开门营业。好吧，太平洋时间早上 6:00 与东部时间不同。将这些存储为 UTC 可能会导致无效假设，尤其是围绕 DST 更改。

在大多数其他情况下，我建议存储为 UTC。但是您必须决定什么最适合您的特定要求。