PHP IntlDateFormatter 严格解析非法日期的 setLenient 配置方法

PHP 接收“31/02/2026”或带尾随字符的日期文本时，不能只看 IntlDateFormatter::parse() 有没有返回数字。默认的宽松解析可能把越界日期纠正成另一个日期；更稳妥的做法是先固定 locale 和 ICU pattern，再调用 setLenient(false)，最后同时检查返回值、offset 和 Intl 错误状态。

官方地址：https://www.php.net/manual/en/intldateformatter.setlenient.php

先把 locale、pattern 和输入边界固定下来

IntlDateFormatter 同时承担本地化格式和解析。locale 决定月份、星期等语言规则，pattern 决定输入的字段形状；这两件事不能用“看起来能解析”代替。下面示例约定输入必须是日/月/四位年份，并使用 UTC 作为解析时区。

setLenient(false);

$input = '28/02/2026';
$offset = 0;
$timestamp = $formatter->parse($input, $offset);

var_dump($timestamp, $offset);
?>

这里的 NONE 只表示不采用预置日期/时间样式，真正的输入边界由最后一个 pattern 给出。若项目接收的是 ISO 8601、带时间或带月份名称的文本，应更换 pattern，而不是继续放宽当前格式。

setLenient(false) 关闭的到底是什么

官方手册将 lenient 定义为解析器对不完全符合模式或日期范围的输入是否采取宽松解释。关闭后，类似“35/13/1971”这类越界日期应进入失败分支；它不会替你检查订单业务规则，也不会自动解决 locale、时区或夏令时选择。

因此，严格模式适合做“这段文本能否按指定日历规则解释”的第一层判断。金额结算日、预约时间等业务场景还应继续检查允许的日期区间和业务时区。

把 parse 结果变成可判断的校验函数

只写 if ($timestamp === false) 仍可能放过部分解析。例如输入后面多出一段文本时，解析器可能已经得到前缀对应的时间值。通过引用传入的 offset 能判断解析停在什么位置；只有它到达输入末尾，才算完整匹配。

setLenient(false);

    $offset = 0;
    $timestamp = $formatter->parse($input, $offset);
    $errorCode = intl_get_error_code();

    // 返回值、完整消费位置和 Intl 错误状态要一起判断。
    if ($timestamp === false || $offset !== strlen($input) || $errorCode !== U_ZERO_ERROR) {
        return ['ok' => false, 'timestamp' => null, 'error' => intl_get_error_message()];
    }

    return ['ok' => true, 'timestamp' => $timestamp, 'error' => null];
}

$result = parseStrictDate('28/02/2026');
var_dump($result);
?>

代码把错误信息留在统一结果里，调用方可以把 ok=false 映射为表单提示，而不是把原始输入继续写入数据库。若输入可能含有多字节文字，仍应以实际 pattern 和测试样例确认 offset 的边界行为。

参数与边界检查清单

常见问题

setLenient(false) 会改变日期显示语言吗？

不会。它只影响解析时是否宽松解释输入；显示语言仍由 locale、pattern 和格式化配置决定。

parse 返回时间戳就一定是完整匹配吗？

不一定。还要检查 offset 是否到达输入末尾，否则可能只是解析了前缀。

为什么严格模式仍要检查时区？

严格模式解决的是文本是否合法，时间戳如何对应到实际时刻仍取决于 formatter 的时区和业务约定。

可以用它替代业务日期范围校验吗？

不能。通过 Intl 解析只说明格式和日期字段可解释，仍需单独判断例如预约日期不能早于今天等规则。