R语言lubridate包dmy函数日期解析格式匹配疑问

前置说明：verbose日志的统计逻辑 #

首先要明确开启lubridate.verbose=TRUE后输出的日志不是「对单个字符串依次尝试每一种格式的过程记录」，而是统计每一个内置候选格式在本次解析全量输入时，独立贡献的新成功解析条目数：

• 解析流程会按预设的优先级顺序遍历所有内置格式，对还没有被成功解析的字符串依次尝试匹配
• 一旦某个字符串被某条格式成功解析，就会从待解析队列里移除，后续格式就算能匹配这个字符串，也不会新增计数、不会在运行时重复尝试该字符串

问题1：为什么dmy会同时尝试%d-%b-%Y与%d-%Om-%Y两种格式 #

两种格式不存在冗余，是分别覆盖不同输入场景的独立规则：

• %d-%b-%Y是专门匹配「日-本地化月份缩写/全称-年」结构的规则，仅能识别当前locale下固定写法的月份文本（比如输入里的英文缩写"Dec"）。如果拿纯数字月份的输入（比如"03-12-2010"）测试这个格式，完全无法匹配，所以这次日志里这个格式的计数为1，刚好对应那个带英文月份的字符串。
• %d-%Om-%Y是lubridate的宽松匹配规则，%Om的识别范围覆盖了带/不带前导零的数字月份、本地化月份名称，但它不是专门针对带分隔符的月份文本做优化的。这次日志里这个格式的计数为1，刚好对应纯数字月份的输入"03-12-2010"。

你之所以觉得两种格式都能解析第一个带英文月份的输入，是因为该输入的结构刚好落在两个格式的匹配范围内，但实际流程中两个格式是分别匹配了输入列表里的不同条目，没有对同一个字符串重复跑解析。

问题2：既然存在%d-%Om-%Y的匹配逻辑，为什么还要校验%d-%m-%Y格式 #

你看到日志里%d-%m-%Y和%d%m%Y的计数为0，并不是dmy在运行时真的对所有输入做了一遍重复校验，本质是lubridate内置格式库的设计逻辑：

• 内置格式库的设计逻辑是，自动遍历的候选列表中，严格匹配规则（以%m为标识）和宽松匹配规则（以%Om为标识）成对排列，且宽松规则的优先级高于严格规则。这两类规则的定位不同：当用户手动指定解析格式使用%m时，会触发严格匹配模式——仅识别固定长度的两位数字月份，不做宽松的文本识别，从机制上避免匹配歧义。
• 这次日志里严格规则的计数为0，并不是运行时真的做了重复校验：所有能被%d-%m-%Y格式匹配的条目（也就是纯数字带分隔符的"03-12-2010"），已经被优先级更高的宽松%d-%Om-%Y规则提前解析完成。严格规则后续遍历的时候，待解析队列里没有可匹配的新条目，所以贡献的成功解析数为0，没有任何运行时的额外开销。
• 严格规则本质是兜底作用：当遇到宽松规则识别有歧义的边缘场景（比如月份文本和数字边界模糊的字符串），严格规则会接住这类解析请求，避免全用宽松规则导致的识别错误。

内容的提问来源于stack exchange，提问作者S.Perera