【发布时间】：2013-02-05 13:34:03
【问题描述】：
为什么 Doctrine 不喜欢旧日期？
Exception was thrown : Could not convert database value "1876-01-01 00:00:00-00:00:00" to Doctrine Type datetime
还有一个：
Exception was thrown : Could not convert database value "0000-00-00 00:00:00-00:00:00" to Doctrine Type datetime
在我的实体中，我确实覆盖了 datetime 和 datetimetz
Type::overrideType('datetime', 'Doctrine\DBAL\Types\VarDateTimeType');
Type::overrideType('datetimetz', 'Doctrine\DBAL\Types\VarDateTimeType');
如果我将日期更新为1976-01-01 00:00:00-00:00:00，它可以正常工作。
更新：
所以我正在运行 Ubuntu 12.04 64 位，我也知道我有 64 位 time_t 从这些测试中工作：
strtotime() 在运行的 32 位和 64 位系统上产生不同的输出 PHP 5.3.3（如前所述）。这会影响“零日期” ("0000-00-00 00:00:00") 以及传统 32 以外的日期 日期范围。
测试：
strtotime("0000-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("0000-00-00 00:00:00") returns -62169955200 on a 64 bit system.
当执行echo strtotime("0000-00-00 00:00:00"); 时，我得到了这个：
php time_test.php -62169966000
那么 Doctrine 有问题吗？
【问题讨论】：
-
32 位
time_t值只能表示 1901 年底和 2038 年初之间的日期。要处理该范围之外的日期，您需要一个 64 位time_t。距离“世界末日”还有不到 25 年的时间——届时基于 1970-01-01 00:00:00 +00:00 纪元的 32 位time_t值将用完。 -
@JonathanLeffler 有没有我可以设置或告诉 Doctrine 使用 64 time_t 的地方？
-
根本不知道教义，我不确定。这将是一个编译时问题；你需要一个 64 位的 PHP 和 Doctrine 版本。如果您在仅 32 位系统上，您可能会卡住。如果您使用的是 64 位系统（即硬件是 x86_64 或其他一些 64 位芯片），那么您可能可以重建所有 64 位，并且它可能会正常工作。然而，这不是一项微不足道的工作。 （对于“重建”，您可以阅读“重建或下载预建的”——您几乎可以肯定需要在 64 位系统上安装 64 位软件。）
-
我不认为这些是 postgresql 时间戳。当然 0000-00-00 不是有效日期。
-
@RichardHuxton 不，但我可以在 Postgresql 中默认为 0000-00-00 时间戳/日期时间
标签： php postgresql datetime doctrine-orm