PHP日期处理需按场景选函数：取当前时间用time()和date()但须设时区；解析字符串优先DateTime::createFromFormat()；复杂计算用DateTime类；格式化注意字符含义及时区统一。
PHP日期时间处理不是“选一个函数就行”，而是得看你要解决什么问题：是取当前时间、格式化显示、解析字符串，还是做跨时区或精确间隔计算。用错函数或忽略时区，轻则显示错几小时，重则逻辑出错。
time() 和 date() 配合使用最常见，但必须注意默认时区
直接调用 time() 返回的是 Unix 时间戳（整数），它本身不带时区信息；date() 默认用这个时间戳 + 服务器本地时区来格式化。如果你没显式设置时区，而服务器在 UTC，你却想显示北京时间，结果就会慢 8 小时。
- 上线前务必在脚本开头加
date_default_timezone_set('Asia/Shanghai') -
date('Y-m-d H:i:s')不传第二个参数时，等价于date('Y-m-d H:i:s', time()) - 避免用
date('h:i A')显示 12 小时制时间——h会把 0 点转成 12，容易混淆，建议统一用H:i - 如果只是要“今天日期”字符串，
date('Y-m-d')比先time()再传参更简洁
strtotime() 解析字符串很方便，但歧义多、不可靠
strtotime() 能认 “明天”、“+2 weeks”、“next Monday”，看起来很智能，但它依赖 PHP 的内部解析器，对中文支持弱、对模糊表达（如 “12/03/2025”）可能按 m/d/Y 或 d/m/Y 猜，结果不稳定。
- 生产环境里，不要用
strtotime('2025-03-12')处理用户输入的日期字符串——它虽然通常能成功，但遇到'2025/03/12'或'12-03-2025'就可能翻车 - 更安全的做法是用
DateTime::createFromFormat()明确指定输入格式，比如DateTime::createFromFormat('Y-m-d', $input) -
strtotime('+0 day')不等于“今天零点”，它返回的是当前秒级时间戳，不是当天 00:00:00；真要取当天起始，得用strtotime('today')或strtotime(date('Y-m-d'))
DateTime 类适合所有非简单场景，尤其是涉及时区、计算、比较
当你需要加减天数后跨月、判断两个时间是否相隔超过 72 小时、或者把用户提交的北京时间存进 UTC 数据库，DateTime 是唯一靠谱的选择。它的方法链式调用清晰，且天然支持时区切换。
立即学习“PHP免费学习笔记（深入）”；
- 创建对象时就可指定时区：
$dt = new DateTime('2026-04-11 15:30:00', new DateTimeZone('Asia/Shanghai')) - 转 UTC 存数据库：
$dt->setTimezone(new DateTimeZone('UTC'))，再用$dt->format('Y-m-d H:i:s') - 计算差值别用时间戳相减——
$dt1->diff($dt2)返回DateInterval，能正确处理闰年、月末天数不一致等问题 - 注意
DateTime是可变对象，$dt->modify('+1 day')会改原对象；如需保留原始值，用clone $dt或改用DateTimeImmutable
date() 格式字符细节决定输出是否符合预期
看似简单的 date('Y-m-d')，换一个字母就可能出错。比如 y（两位年份）和 Y（四位）、m（补零月份）和 n（不补零）语义不同；H 和 h 对应 24 小时与 12 小时制，混用会导致凌晨 0 点显示成 12，中午 12 点也显示成 12。
- 对外展示或日志记录，优先用
Y-m-d H:i:s（ISO 8601），排序和调试都方便 - 中文界面中用
date('Y年m月d日 H:i')没问题，但别用l（英文星期名）或F（英文月份名），它们不会自动本地化 -
date('U')返回时间戳，和time()效果一样，但没必要——time()更直白、无额外开销 - 要输出“第几周”，用
W（ISO 周序号），不是w（星期几数字），后者返回 0~6，容易误读
真正容易被忽略的是：时区设置是一次性的全局行为，date_default_timezone_set() 必须在任何日期函数调用前执行；而 DateTime 对象的时区是实例级的，可以各自独立。这两个层级混着用，不出问题才怪。
