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


PHP/MySQL - Storing of dates for use with date selection reports across timezones

目前正在辩论存储日期的最佳方式,并希望有经验的评论 - 寻找"为什么"而不是"如何"。

场景:

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

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

我们的问题是 - 为什么要麻烦地以 UTC 存储

- 以 UTC 存储日期有什么优势。从我们的角度来看,我们有客户指定的时区,所以如果我们将日期/时间存储在他们的正确时区,那么这是我们每笔交易运行一次的计算 - 此后他们的所有报告都将在没有任何日期转换计算的情况下工作。

由于我们读到的大多数问题和评论都涉及"如何",我们认为一定有一些关于"为什么"的东西我们错过了。

因此,总而言之,在我们做出决定之前,我们错过了一些东西 - 是否有绝对的"必须将日期存储为 UTC"的原因?

感谢您的阅读 - 任何评论表示赞赏。

为什么要麻烦地在 UTC 中存储?

UTC 中存储时间没有麻烦。IMO 如果日期时间字段都位于同一时区,则维护日期时间字段会更容易,而不是表的每条记录都位于不同的时区以及与user表的关系告诉您该字段位于哪个时区(甚至荒谬的方法是将偏移量像+02:00存储在额外的字段中(。

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

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

  • 如果用户更改了时区怎么办?
  • 如果您要升级系统,以便用户可以为每个请求指定时区,该怎么办?
  • 等。

是否有绝对的"必须将日期存储为 UTC"的原因?

Ofc不是;这完全是关于你的设计。你选择的就是你用的;试想一下,对于未来的升级等,什么对您来说会更容易。

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

在我看来,最好将日期/时间存储为数据库中的 unix 值。然后,您有一个确切的数字,可以轻松操作以使用存储的时区或其他方式以您喜欢的方式显示,并且至关重要的是,如果您决定更改其显示方式,它将很快更改。