MySQL/Aurora DateTime字段偶发写入1970异常时间而非NOW()值问题

首先你代码里存在一个显性逻辑问题：当前INSERT语句的VALUES列表并没有绑定:DateCreated参数，第四个值直接硬编码了MySQL内置函数NOW()，也就是说DateCreated字段的写入值完全来自数据库服务端的当前时间，和你API层生成的$currentDatetime没有任何关联，这就是该字段始终写入正常的核心原因。

你看到的异常值1970-01-01 01:00:00是Unix时间戳0（纪元零点）在东八区时区下的标准转换结果，出现该值的本质原因是：偶发场景下，绑定给:DueDateTime的入参不是合法的Y-m-d H:i:s格式时间字符串，而是被解析为数值0，MySQL将数值0按时间类型转换后就得到了这个异常值。

常见触发场景如下：

• 变量覆盖：在给业务数组赋值后、SQL执行前的逻辑链路中，存在偶发分支将DueDateTime的值覆盖为空字符串、false、0这类非合法时间格式的值。最常见的问题是$Data数组存在合并上游请求参数的逻辑——如果上游请求携带了空值/0值的DueDateTime参数，会直接覆盖你之前默认赋值的$currentDatetime；而DateCreated因为走硬编码NOW()逻辑，完全不受参数覆盖影响，因此始终正常。两套独立系统都出现相同问题，基本可以确定是同类参数覆盖逻辑导致的共性问题。
• PDO绑定类型自动识别错误：PDO默认不指定参数类型时，会根据传入值的PHP类型自动选择绑定类型，如果偶发场景下$Data['DueDateTime']是整型0（比如参数被隐式转为整型、上游传值为0），PDO会按整型参数绑定，MySQL会直接将传入的整型0识别为Unix时间戳0，转换后得到异常时间值。
• 时区配置不一致：如果PHP运行时区、MySQL连接时区配置不统一，极端场景下时间字符串解析失败会回退为0值，但这类问题一般为必现，不会随机出现，排查优先级低于前两项。

• 先修正INSERT语句的硬编码问题：如果业务要求两个时间字段取统一的应用层生成时间，将VALUES列表中的硬编码NOW()替换为:DateCreated占位符，保证两个时间字段走相同的参数绑定逻辑，消除应用层时间和数据库层时间不一致的隐患。
• 增加执行前参数日志：在SQL执行前打印$Data['DueDateTime']的实际值和变量类型，捕获异常出现时的参数状态，可直接定位到是哪个逻辑分支覆盖了正确的时间值。重点排查$Data数组的赋值逻辑，确认是否存在直接合并请求参数、未做字段默认值兜底的逻辑——大部分框架默认会将请求参数直接注入到模型/数据数组中，只要请求带了空的同名字段，就会覆盖预赋值的默认时间。
• 强制指定参数绑定类型：给时间字段的参数绑定明确指定类型为字符串，执行时传入PDO::PARAM_STR参数，避免PDO自动类型判断将值转为整型导致时间解析错误。
• 统一时区配置：将PHP的date.timezone配置、MySQL连接的会话时区统一设置为Asia/Shanghai（东八区），消除隐式时区转换导致的解析异常。

内容的提问来源于stack exchange，提问作者Nathan Best