在数据库中将日期和时间存储为纪元与本机日期时间格式答案

【问题标题】：Storing date and time as epoch vs native datetime format in the database在数据库中将日期和时间存储为纪元与本机日期时间格式
【发布时间】：2011-02-07 02:45:11
【问题描述】：

对于我的大多数任务，我发现使用 epoch 格式的日期和时间要容易得多：

计算时间跨度很简单

或确定某个事件是在另一事件之前还是之后发生，

如果数据来自不同的地理来源，我不必处理时区问题，

在脚本语言的情况下，当我请求一个日期时间类型的列时，我通常从数据库中得到的是一个字符串，我需要对其进行解析才能使用它。

这个列表可以继续，但对我来说，为了保持我的代码可移植性，这足以抛弃数据库的本机日期时间格式并将日期和时间存储为整数。大家觉得呢？

【问题讨论】：

标签： datetime scripting-language epoch

【解决方案1】：

您应该能够通过使用 UTC 日期时间来解决时区问题。我知道 C 具有将纪元时间转换为 UTC 的功能。我找不到另一条路，这让我很困惑。

【讨论】：

那么，为什么首先要进行这个额外的转换步骤？
将纪元时间转换为UTC是身份操作。自 1970 年 1 月 1 日 00:00:00 UTC 以来的纪元是秒（模闰秒）。

【解决方案2】：

我认为我已经习惯了 MVC 中的正确模型对象和方法，这些日期和时间功能变得微不足道。我依赖日期和时间库进行计算。很少有时候我必须自己编写，实际上那些时候我忽略了这个功能已经在库中的事实。如果您使用 PHP，请从 Zend 框架中获取日期和时间库。一旦你开发了你的模型，就可以重用它。然后你就不用关心日期和时间是如何存储在数据库中的。

【讨论】：

如果我需要从 PHP 和 Perl 访问相同的数据怎么办？还带来了额外的 Date 对象层影响性能 - 很少记录可以，但在大型数据集上会有所不同
在我的工作中，我经常从 PHP 跳到 Perl 并返回很多，大多数 PHP 代码可以很容易地转换为 Perl。关于性能抽象几乎不是瓶颈。如果事情是适当抽象的，那么提高代码的性能会更容易，因为可以重构模型而不会干扰应用程序的其他部分。也非常适合测试。

【解决方案3】：

使用数据库的DATETIME 类型的主要原因是POSIX time_t 的范围非常有限；您不能存储臭名昭著的 Y2038 之后或 1904 年左右之前的日期。由于许多数据库需要存储历史或未来日期，因此有一个完整的范围且通常可移植的 DATETIME；如果事实上 POSIX 纪元时间对您更有用，那么请继续使用它们。

【讨论】：