在我正在运行的 PHP 站点中，用户表有一个名为 user_last_login 的日期时间字段。
我不时注意到，对于随机用户，该字段的值为 1969 年 12 月 31 日，而其他数千名用户仍然存储了准确的日期。
以下 PHP 代码用于在登录时生成此值：
$login_success_query->bindValue(':user_last_login', date("Y-m-d H:i:s"), PDO::PARAM_STR);
什么可能导致这个意外的默认日期值？
编辑（显示代码）：
$user_last_login = strtotime($enrolled_user['user_last_login']);
$user_last_login = date( 'F j, Y | g:i a', $user_last_login );
【问题讨论】：
不再是狂野射击
date("Y-m-d H:i:s")
因此，您以正确的 MySQL 日期时间格式存储日期。你的显示器有时会显示
December 31, 1969
这意味着您显然是以不同的格式显示它。因此，您用于转换该日期的代码存在问题。最有可能的问题是月份先到还是天先到。查看该代码，您将看到当您的代码使用一个月的日期时发生了什么，这会导致错误，然后将打印的日期默认为 unix epoch。
您还可以通过运行查询来查看所有存储的日期时间值来验证这个假设，如果您总是使用date("Y-m-d H:i:s") 来存储日期，那么它绝对不可能损坏 em> 有时是随机的。
上次登录：从不 ;)就是答案。
【讨论】：
如果你将一个纪元（自纪元以来的秒数）转换为一个日期，你通常会得到一个不错的合理值：
例如：
echo date('Y-m-d H:i:s', 1453266106); //2016-01-20 00:01:46
但是如果你传入0，你会得到纪元的日期：
echo date('Y-m-d H:i:s', 0); // 1969-12-31 19:00:00
检查您的代码是否有任何其他位置，您正在更新user_last_login，并将第二个（整数）参数传递给date
【讨论】：
看起来您的时间有时可能无效。见Prevent PHP date() from defaulting to 12/31/1969。
您可以尝试在插入之前先检查时间（如链接所示）以防止这种情况发生。但是你仍然需要弄清楚为什么它有时是无效的。为此，您需要更好地了解时间的来源。
【讨论】：