在 Python 3.14 中，使用 datetime.strptime 解析“02-29”这类只给月日、不给年份的文本时，未指定的年份会从默认值 1900-01-01T00:00:00.000 取得；1900 年不是闰年，因此即使业务上想表达某个闰年的二月二十九，解析阶段仍可能报错。这不表示已经核实客户的实际年份；它解释的是格式缺年时，解析器采用默认年份作校验和构造。本题不把解析器填入的默认年份当作用户真实业务年份。
适用：Python 3.14 的 datetime.strptime；对象是格式串中只含月日、原始文本为“02-29”的调用。是否出现同样现象，还要结合实际解释器、运行平台和调用条件核对，不能仅凭版本号推断所有调用都会报错。
观察：先在只读日志或去敏样本中找到调用 datetime.strptime 的格式串，确认它是否只包含 %m 和 %d 而没有年份字段；若格式串确实缺年，再记录原始日期文本是否为“02-29”。结果条件是：格式串缺年且文本为“02-29”时，默认 1900 年参与构造，1900 非闰年，二月二十九不成立，调用可能抛出与日期无效相关的异常。另一个观察点是 Python 3.13 起的“日无年”弃用警告：如果运行环境出现相关警告，应记录警告文本和版本；若日志里已有年份字段，或原始文本不是“02-29”，则不能仅凭本题条件推断同类报错。只读保留原格式和异常，不在客户数据中猜写年份来通关。
风险：把只含月日的格式用于闰日，可能在解析阶段失败，导致后续流程拿不到日期对象；即使换成其他月日，未指定年份时仍会从 1900-01-01 默认值取得，业务年份与解析结果可能不一致。这里不能靠猜测把年份写死，也不应把 3.13 起的弃用警告理解为业务年份已被修正。对常州台式电脑上的授权软件，风险还在于用临时改动掩盖格式串问题，使同一批数据在不同调用点表现不一致。
下一步：常州天宁区台式电脑用户可先保留只读日志和去敏材料，整理四项信息：实际 Python 版本、datetime.strptime 的格式串、原始日期文本（可脱敏）、异常或警告原文；不要提交完整客户文件。然后用去敏后的最小调用片段在隔离环境核对，确认本次错误是否符合缺年且月日为二月二十九这一分支，不把其他日期错误一并归因。若需要人工协助，可通过 400-877-9605 咨询电脑快修网；该号码只作咨询，电脑快修网是信息展示与第三方维修对接平台，实际范围和安排需确认。