strtotime 解析失败返回 false 而非异常，需用 === false 显式判断；推荐 DateTime 类替代 date/strtotime 组合，避免时区与边界问题；date() 格式符 Y/y、m/n 等差异影响兼容性；时区应通过 date_default_timezone_set() 全局设置。
strtotime 解析失败时返回 false 而不是报错
strtotime 遇到无法识别的日期字符串（比如 "2023-02-30"、"next mondayx"、空字符串或 null）会静默返回 false，而不是抛异常。很多代码直接拿这个结果塞进 date()，结果输出 1970-01-01 —— 因为 date('Y-m-d', false) 等价于 date('Y-m-d', 0)。
实操建议：
- 永远用
=== false显式判断返回值，别用!strtotime(...) - 对用户输入或外部接口来的日期字符串，先校验再解析：
if (($ts = strtotime($input)) === false) { throw new InvalidArgumentException("Invalid date format: $input"); } - 注意时区影响：
strtotime('12:00')按当前脚本时区解析，不是 UTC；如果源数据没带时区信息，别假设它和服务器一致
date() 格式化时 Y 和 y、m 和 n 的区别很关键
date() 的格式字符看似简单，但 Y 和 y、m 和 n 这类差异直接影响数据可读性和下游系统兼容性。比如 API 要求 ISO 8601 全年份（Y），你用了 y 就变成两位数，2024 年输出 24，对接方可能直接拒收。
常见混淆点：
立即学习“PHP免费学习笔记（深入）”；
-
Y是 4 位年份（2024），y是 2 位（24） -
m是带前导零的月份（01–12），n是无前导零（1–12），JSON 或数据库字段要求固定宽度时必须用m -
H（24 小时制，00–23）和h（12 小时制，01–12）混用会导致时间逻辑错乱，比如date('h:i A', strtotime('15:30'))输出03:30 PM，但若漏了A就只剩03:30，意义全失
PHP 5.6+ 推荐优先用 DateTime 类而非 date/strtotime 组合
不是因为 date() 和 strtotime() 不能用，而是它们在处理时区切换、相对日期计算（如“上个月最后一天”）、跨日加减时容易出错且不可读。比如 strtotime('-1 month', strtotime('2023-03-31')) 返回 2023-03-03（不是 2 月 28 日），这是 C 库底层行为，PHP 不做修正。
更可靠的做法：
- 用
DateTime对象封装时间，显式指定时区：$dt = new DateTime('2023-03-31', new DateTimeZone('Asia/Shanghai')); - 用
modify()或add()处理相对运算：$dt->modify('last day of previous month');这样才真得是上个月底 - 跨时区转换用
setTimezone()，比手动加减秒数安全得多
时区设置不生效？ini_set('date.timezone') 只影响当前请求
很多人在脚本开头写 ini_set('date.timezone', 'Asia/Shanghai')，以为全局搞定，结果 CLI 下跑正常，Web 服务器里还是 UTC —— 因为 php.ini 中的 date.timezone 优先级更高，而且 ini_set() 在某些 SAPI（如 PHP-FPM）中被禁用或无效。
真正有效的做法：
- 改
php.ini文件里的date.timezone = Asia/Shanghai，重启服务 - 或在脚本最开始用
date_default_timezone_set('Asia/Shanghai')，它比ini_set更可靠，且对date()、strtotime()、DateTime全局生效 - 注意：
date_default_timezone_set()不能传缩写（如CST），必须用 Olson 数据库名（Asia/Shanghai、America/New_York）
时间处理最麻烦的从来不是语法，而是隐含的时区上下文和边界情况。比如 strtotime('2024-02-29 +1 year') 在非闰年怎么算，DateTime::add(new DateInterval('P1M')) 怎么处理月底，这些细节不验证就上线，出问题时很难回溯。
