strtotime仅可靠解析常见习惯格式如”2024-05-20″、”May 20, 2024″、”next Monday”等，对中文、日月年顺序、ISO 8601等易失败，需配合防护逻辑与DateTime::createFromFormat兜底。
strtotime 能转哪些格式的日期字符串
strtotime 并不是万能解析器，它只对符合常见习惯的文本敏感。比如 "2024-05-20"、"May 20, 2024"、"next Monday"、"+3 days" 这类能被自然语言识别的写法才可靠。
以下写法大概率失败：
-
"2024/05/20 14:30:00"（部分环境可，但不保证） -
"20-05-2024"（日月年顺序易被误判为美式） -
"2024年5月20日"（中文字符直接返回false） -
"2024-05-20T14:30:00Z"（ISO 8601 格式建议用DateTime::createFromFormat或date_create）
strtotime 返回 false 的常见原因
返回 false 不代表写错了，而是解析失败。最常踩的坑是时区和格式模糊：
- 服务器时区设为
UTC，而输入"12:00"没带时区，strtotime可能按 UTC 解析，导致时间偏移 - 输入
"05/20/2024"：在en_US环境下是“5月20日”，在en_GB下可能报错或误判为“无效日” - 输入空字符串、
NULL、含不可见字符（如u{FEFF}bom）都会直接返回false - php 8.0+ 对超长/非法年份（如
"10000-01-01"）更严格，可能拒绝解析
安全使用 strtotime 的实操建议
别裸用 strtotime($str)，加一层防护和兜底：
立即学习“PHP免费学习笔记（深入）”；
if ($timestamp = strtotime($dateString)) { echo date('Y-m-d H:i:s', $timestamp); } else { // 记录原始字符串用于排查 error_log("strtotime failed on: " . var_export($dateString, true)); // 可选 fallback：尝试 DateTime 构造 $dt = DateTime::createFromFormat('Y-m-d', $dateString); if ($dt && $dt->format('Y-m-d') === $dateString) { echo $dt->format('Y-m-d H:i:s'); } }关键点：
- 永远检查返回值是否为
false，不能只用=== 0判断（1970-01-01 00:00:00 也返回 0） - 若已知固定格式（如
Y/m/d），优先用DateTime::createFromFormat()，它不依赖自然语言解析，更稳定 - 涉及用户输入时，先
trim()再判断长度，避免空格干扰 - 跨时区场景下，显式设置时区：
date_default_timezone_set('Asia/Shanghai')
替代方案：什么时候不该用 strtotime
当你要处理以下情况时，strtotime 就不是最优解：
- 解析带毫秒的 ISO 时间（如
"2024-05-20T14:30:00.123Z"）→ 用DateTime::createFromFormat('Y-m-dth:i:s.uZ', $str) - 从数据库读出的
datetime字段（如"2024-05-20 14:30:00"）→ 直接传给new DateTime($str)更清晰 - 需要验证格式合法性（比如必须是“yyYY-MM-DD”）→ 先正则匹配
/^d{4}-d{2}-d{2}$/，再用DateTime::createFromFormat - 批量处理上万条日期字符串 →
strtotime是函数调用开销较大，预编译格式 +DateTime::createFromFormat更快
真正难的不是“怎么转”，而是“怎么确定它真的转对了”——尤其当输入来源不可控时，strtotime 的隐式行为比显式格式解析更容易埋雷。