PHP日期时间怎么格式化_date和strtotime函数用法【说明】

陆砚码

2026-10-11 • 👁 0人浏览过

PHP日期处理应优先使用DateTime类而非date()/strtotime()，因后者存在时区混乱、字符串解析失败、格式校验缺失等问题，尤其在多时区、毫秒精度、输入验证等场景下不可靠。 PHP 里格式化日期时间，核心就靠

date()

和

strtotime()

，但直接套用常出错——不是时区不对，就是字符串解析失败，或者格式符记混。 date() 函数怎么用才不翻车

date()

只负责「格式化」，它不解析字符串、不处理时区转换，只把一个 Unix 时间戳转成你想要的字符串样式。第一个参数是格式字符串，比如

"Y-m-d H:i:s"

，其中

Y

是 4 位年份，

y

是 2 位；

H

是 24 小时制，

h

是 12 小时制——大小写敏感，写错就显示 00 或乱值第二个参数是可选的时间戳，不传就默认用当前时间（

time()

），但这个“当前”受

date_default_timezone_set()

控制，没设就用系统默认时区，线上和本地常不一致常见错误：

date("Y-m-d", "2023-10-05")

—— 第二个参数必须是整数时间戳，传字符串会转成 0，结果永远是 1970-01-01 strtotime() 解析字符串的边界情况

strtotime()

是把自然语言风格的日期字符串转成时间戳的函数，但它不是万能解析器，很多写法它根本认不出来。支持常见格式：如

"2023-10-05"

、

"next Monday"

、

"+2 days"

，但像

"05/10/2023"

在不同地区可能被当成月/日/年或日/月/年，结果不可控返回值是整数时间戳，失败时返回

false

，但 PHP 默认开启

error_reporting

时不会报错，容易静默失败——务必用

=== false

判断它也受时区影响：没设默认时区时，输入

"now"

或

"today"

会按服务器本地时区算，不是 UTC 也不是用户所在时区 date() 和 strtotime() 组合使用的典型陷阱很多人写

date("Y-m-d", strtotime($_POST['date']))

就以为万事大吉，其实埋了三颗雷。 PHP 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。下载立即学习 “ PHP免费学习笔记（深入） ”；用户输入

"2023/10/05"

，在部分 PHP 版本中

strtotime()

会解析失败（尤其 Windows 下）；建议统一用

DateTime::createFromFormat()

替代，或先正则标准化格式前端传来的 ISO 格式时间如

"2023-10-05T12:30:45Z"

，

strtotime()

虽能识别，但末尾

Z

表示 UTC，而

date()

输出时仍按默认时区格式化，结果时间偏移想输出北京时间（UTC+8），不能只靠

date_default_timezone_set("Asia/Shanghai")

，还要确认服务器时区没被 Docker 或 Nginx 覆盖；更稳妥的是用

DateTime

类显式指定时区替代方案：什么时候该放弃 date/strtotime 当需求涉及时区转换、多格式输入、或需要验证合法性时，

date()

和

strtotime()

的脆弱性会快速暴露。用户提交的日期字段要校验是否真实存在（如 2023-02-30），

strtotime()

会自动“纠正”成 2023-03-02，而

DateTime::createFromFormat("Y-m-d", $input)

配合

getLastErrors()

才能真正判断格式与逻辑是否合法处理带毫秒的 ISO 时间（

"2023-10-05T12:30:45.123Z"

），

strtotime()

直接丢弃毫秒，

DateTime

支持完整解析跨时区调度场景（如“纽约用户预约，按伦敦时间提醒”），硬靠

strtotime()

加减秒数极易出错，

DateTimeZone

setTimezone()

是唯一靠谱路径真正难的不是写对一行

date("Y-m-d", time())

，而是当输入不可控、时区不明确、需求要验证或转换时，你还敢不敢继续用这两个函数。

相关文章