PHP字符串转日期方法及技巧

strtotime()适合解析常见可读日期字符串但依赖时区且易歧义；DateTime::createFromFormat()更安全，需严格匹配格式；中文日期须预处理；时区设置不当会导致时间戳错误。

直接用 strtotime() 解析常见格式字符串

strtotime() 是 PHP 最常用的字符串转时间戳函数，适合处理「人类可读」的日期字符串，比如 "2024-05-20"、"next Monday"、"+3 days"。它会自动识别多种分隔符（-、/、空格）和顺序（年月日 / 月日年），但依赖系统时区设置，且对模糊格式容忍度高——这既是优点也是隐患。

实操建议：

• 确保 date_default_timezone_set() 已正确设置，否则可能返回意外的时间戳（例如本地时区为 UTC+8 但未设，"2024-05-20" 会被当 UTC 解析）
• 对固定格式（如 "Y-m-d H:i:s"），优先用 DateTime::createFromFormat()，strtotime() 在遇到 "01/02/2024" 这类歧义字符串时可能误判为美式（月/日/年）而非中式（日/月/年）
• 返回值必须检查：if (false === $timestamp) { /* 解析失败 */ }，strtotime() 解析失败时返回 false，不是 -1 或 0

用 DateTime::createFromFormat() 精确控制格式

当你明确知道输入字符串格式（如 "20240520"、"20/05/2024 14:30"、"May 20, 2024"），DateTime::createFromFormat() 是更安全的选择。它不猜测，只按你给的格式模板匹配，解析失败直接返回 false，不会悄悄“纠正”错误。

实操建议：

• 格式字符必须严格对应：年用 Y（4位）或 y（2位），月用 m（补零）或 n（不补零），日用 d 或 j；"2024-5-20" 需用 "Y-n-j"，不能写成 "Y-m-d"
• 支持字面量：格式中非占位符字符（如空格、T、GMT）需原样出现在字符串中；"2024-05-20T14:30:00+08:00" 对应 "Y-m-d\TH:i:sP"（注意 \T 转义）
• 解析后可用 $dt->getTimestamp() 拿时间戳，或 $dt->format('Y-m-d') 输出新格式，避免隐式类型转换问题

DateTime::createFromFormat('Y/m/d H:i', '2024/05/20 13:45');

处理中文日期字符串（如“2024年5月20日”）

PHP 原生函数不识别中文年月日关键字，strtotime("2024年5月20日") 会返回 false。DateTime::createFromFormat() 同样无效，因为 年、月、日 不是标准格式字符。

实操建议：

• 先用 str_replace() 或正则预处理：str_replace(['年', '月', '日'], ['-', '-', ''], $str) → "2024-5-20"，再进 DateTime::createFromFormat('Y-n-j', ...)
• 若含“星期几”，如“2024年5月20日星期一”，需额外提取并映射到数字（周一→1），但通常业务中这类字符串应由前端或录入端标准化，后端不建议承担语义解析责任
• 警惕全角字符：用户粘贴可能带全角 －、：，需用 mb_ereg_replace() 或 strtr() 清洗，否则格式匹配直接失败

时区与时间戳转换的隐性陷阱

字符串转日期本质是「文本→时间点」映射，而时间点必须绑定时区才有意义。PHP 默认用 date.timezone 设置的时区解释字符串，但开发者常忽略这点，导致线上环境和本地结果不一致。

实操建议：

• 不要依赖默认时区：显式传入时区对象，如 new DateTime('2024-05-20', new DateTimeZone('Asia/Shanghai'))
• 数据库存时间戳（int）比存格式化字符串更可靠；若存 datetime 字段，确保 MySQL 时区与 PHP 一致（SELECT @@time_zone），否则 FROM_UNIXTIME() 可能偏移 8 小时
• 用 DateTime::setTimezone() 转换时区时，操作的是时间点本身（UTC 基准不变），不是简单加减小时数；$dt->setTimezone(new DateTimeZone('UTC')) 才能得到该时刻的 UTC 表示

最易被忽略的是：同一字符串在不同时区调用 strtotime() 会产生不同时间戳，而这个差异在调试时很难被肉眼发现。