PHP/MySQL - 存储日期以用于跨时区的日期选择报告答案

【问题标题】：PHP/MySQL - Storing of dates for use with date selection reports across timezonesPHP/MySQL - 存储日期以用于跨时区的日期选择报告
【发布时间】：2013-09-30 21:59:52
【问题描述】：

目前正在讨论存储日期的最佳方式，并希望有经验的 cmets - 寻找“为什么”而不是“如何”。

场景：

我们正在开发一个允许客户（跨多个时区）创建交易数据的系统。在注册时，客户将指定他们的时区。系统的很大一部分围绕着客户端运行关于交易数据的日期和时间相关报告。

我们已经阅读了许多关于存储事务日期字段的最佳方式的问题和 cmets，大多数人说存储为 UTC，然后执行各种与日期和时间相关的函数来计算各个时区的时间，以便运行选择报告。

我们的问题是 - 为什么要麻烦以 UTC 格式存储 - 以 UTC 格式存储日期有什么好处。从我们的角度来看，我们有客户指定的时区，所以如果我们将日期/时间存储在他们正确的时区中，那么我们每次交易都会运行一次计算 - 此后他们的所有报告都将在没有任何日期转换计算的情况下工作。

由于我们阅读的大多数问题和 cmets 都提到了“如何”，我们认为必须有一些关于“为什么”的东西我们错过了。

因此，总而言之，在我们做出决定之前，我们是否遗漏了一些东西 - 是否有绝对的“必须将日期存储为 UTC”的理由？

感谢您的阅读 - 感谢任何 cmets。

【问题讨论】：

客户是否只报告自己的计算？
每个客户只能访问他们自己的交易数据，并且没有逻辑上的理由或统计要求来运行多客户合并数据的报告。
感谢您的所有 cmets - 很好的辩论 Glavic。在没有绝对理由将日期存储为 UTC 的情况下，根据我们的问题，我们将选择 Labib 的答案作为他的评论“在受控环境中它是完全一样的”。

标签： php mysql date datetime

【解决方案1】：

为什么要费尽心思存储在 UTC 中？

在 UTC 中存储时间没有问题。如果日期时间字段都在同一个时区，IMO 更容易维护它们，而不是表的每条记录都在不同的时区并且与 user 表的关系告诉你该字段在哪个时区（甚至荒谬的方法是存储在额外的字段中像+02:00 一样偏移）。

在注册时，客户将指定他们的时区。

想想当你添加功能时会发生什么：

如果用户更改了那里的时区怎么办？
如果您要升级系统以使用户可以为每个请求指定时区，该怎么办？
等

是否有绝对的“必须将日期存储为 UTC”的原因？

当然不是；这完全取决于您的设计。你所选择的就是你所使用的；想想什么对你来说更容易，对于未来的升级等等。

【讨论】：

Glavic - 感谢您的评论 - 只有一点 -> '如果用户更改他们的时区怎么办' - 我们认为这是不以 UTC 存储时间的原因。使用 UTC 格式更改时区会更改所有历史交易时间，从而破坏系统的完整性。 ——
我不同意，但这取决于您的项目逻辑。如果您将所有用户记录保存在他的时区；并且用户更改了他的时区，那么您将需要更新他的所有记录，以修复他的记录以匹配他的新时区。在时区更改时，您必须更新记录，这对于大型数据集来说是不行的。如果您知道所有记录都在相同的偏移量中，我看不到这个问题。
“在时区更改时，您必须更新记录” - 我们显然生活在不同的世界中 - 在我的“系统完整性”是王道 - 更改历史记录会打开业务处理问题的雷区，这可能会使公司付出代价一切。无论如何，我认为我们偏离了我们的主要观点。因此，可以说客户不会更改时区并将此讨论搁置一天。谢谢。
如果我对您的理解正确，您将在（比如说）用户表中保存时区，例如+02:00。他的所有相关记录都将在他的时区中，例如... 08:00。但是如果用户将他的时区（可以说是可能的）更改为+03:00，那么他所有已经保存的记录都是无效的，因为... +08:00 现在是时区+03:00，这是无效的；我就是这样说更新的；我同意，这是非常糟糕的方法，我从未提出过这种方法；我的方法是，将所有内容保存在一个偏移量中（最好是 UTC），就是这样。
“他所有已经保存的记录都是无效的” - 谁说的？根据您的示例：- Joe Blogs 每天早上 8 点在系统上输入交易。 Joe Blogs 公司向东移动 -> 时区变化 +1。像往常一样，Joe Blogs 每天早上 8 点上班，并在系统上输入一笔交易。但现在 Joe Blogs 查看历史交易并发现在搬迁之前他在上午 9 点创建了这些交易。在 Joe Blogs 的世界里，系统是错误的——他是在早上 8 点进入的。在现实世界中，您永远不能僵化到将这种类型的改变强加给客户——记住客户才是王道:-)

【解决方案2】：

不，我认为这没有“必须”！这完全是一个设计问题，您选择使用什么将决定事情的工作方式，无论哪种情况，这只是一个参考问题，建议使用UTC的人，是因为它是众所周知和经过验证的参考，无论您的程序有多大或您的客户在哪里，参考总是在那里，但是如果您使用另一个时区，事情会以同样的方式工作，但您选择的时区将是参考，这可能在某些情况下会引起误解，但在受控环境中仍然是完全一样的。希望我回答了你的问题。

【讨论】：

【解决方案3】：

在我看来，最好将日期/时间作为 unix 值存储在数据库中。然后，您就有了一个准确的数字，可以很容易地操纵它以您喜欢的方式显示，使用存储的时区或其他方式，至关重要的是，如果您决定更改它的显示方式，它会很快改变。

【讨论】：