date() 和 time() 是最常用但最容易出错的组合
绝大多数 PHP 日期操作都从 time() 拿时间戳、用 date() 格式化开始，但它俩默认依赖服务器时区——当前时间是 2026年3月4日，星期三7时7分，但如果你没设时区，date("Y-m-d H:i:s") 可能输出 UTC 时间（即 2026-03-04 00:07:00），和你本地差七八个小时。
- 必须在脚本开头调用
date_default_timezone_set("Asia/Shanghai")，不能只靠 php.ini 配置，因为 CLI 和 Web 环境可能不一致 -
date()的第二个参数可选，但显式传入time()返回值比省略更安全，尤其在批量处理历史时间时 - 格式字符串里带反斜杠要小心：
date("Y-m-d \a\t H:i")必须用单引号包裹，否则\a被解释成响铃字符 - 别用
date("l, F jS, Y")直接显示中文，它输出英文星期和月份；需要多语言请用IntlDateFormatter，不是date()的责任
strtotime() 不是“万能解析器”，而是有明确边界的时间转换工具
strtotime() 看似智能，实则规则固定：它只认 ISO 8601、常见英文短语（如 "next Monday"）、相对偏移（如 "+2 months"），对模糊表达（如 "上个月底"、"本月第一个工作日"）会失败或误判。
- 输入字符串为空、含非法字符、或超出 PHP 支持范围（约 1901–2038 年）时，
strtotime()返回false，不是 0 —— 必须用=== false判断，不能只写if (!$ts) - 相对时间如
"+1 month"在跨月时行为特殊：2026-01-31 执行strtotime("+1 month")得到的是 2026-03-03（不是 2026-02-28），因为 2 月没有 31 日，PHP 自动顺延 - 想解析自定义格式（如
"2026/03/04 07:07"），优先用DateTime::createFromFormat()，比strtotime()更可控、更少歧义
DateTime 类比函数式 API 更可靠，尤其涉及时区切换或加减运算
当你要做“把北京时间 2026-03-04 07:07 转成纽约时间”或“从今天起加 45 天再减去 3 小时”，用 date()+strtotime() 容易绕晕，而 DateTime 把时间、时区、运算封装成对象，逻辑清晰。
- 创建时就指定时区：
$dt = new DateTime("2026-03-04 07:07:00", new DateTimeZone("Asia/Shanghai"))，避免后续setTimezone()出错 - 加减用
modify()或add()方法，比如$dt->modify("+45 days")比strtotime("+45 days", $ts)更易读且支持链式调用 - 注意
DateTimeImmutable的存在：它每次操作返回新对象，原对象不变，适合函数式风格或防止意外修改共享时间对象 - 数据库存取时，
DateTime::format("Y-m-d H:i:s")输出 MySQL 兼容格式，但记得确认 MySQL 时区设置是否与 PHP 一致，否则写入和查询结果可能错位
checkdate() 和 date_parse() 是验证环节里常被跳过的“守门员”
用户提交 "2026-02-30" 或 "abc" 这类非法日期字符串很常见，但很多代码直接扔给 strtotime()，结果返回 false 却没检查，导致后续 date() 输出 1970 年 1 月 1 日这种“幻觉时间”。
立即学习“PHP免费学习笔记（深入）”；
-
checkdate(2, 30, 2026)明确返回false，比strtotime()更早暴露问题，适合表单提交后的第一道校验 -
date_parse("2026-03-04 07:07:xx")返回数组，其中["error_count"]和["warnings"]字段能告诉你哪部分解析失败，比单纯看false更细致 - 不要用
getdate()做格式化输出，它返回关联数组，字段名全是英文缩写（如"mday"、"mon"），易错且不可控；它更适合调试时快速看结构，不是生产级格式化工具
真正麻烦的从来不是“怎么写出来”，而是“什么时候该用哪个函数”——strtotime() 适合简单转换，DateTime 适合复杂逻辑，checkdate() 适合输入防御。漏掉时区设置、忽略返回值类型、混用不同精度的时间戳（秒 vs 微秒），这些才是线上出问题的高频原因。
