Python中datetime.strptime为何不校验%Y等指令的补零格式？如何实现严格格式校验？

没错，这确实是datetime.strptime的预期行为。我当初第一次遇到这个问题时也挺困惑的——Python的strptime设计上更偏向「灵活解析」，而不是「严格格式校验」：它只会检查解析出来的数值是否合法（比如年份是整数、月份在1-12之间、小时在0-23之间等），但不会校验输入字符串的位数是否完全符合格式指令的补零要求（比如%Y不强制要求四位、%m不强制要求两位）。

为什么你的测试用例里只有最后一行报错？ #

咱们拆解一下你的代码逻辑：

• '20101124-134523'：完全匹配%Y%m%d-%H%M%S的补零格式，自然解析正常。
• '101124-134523'：这里其实会把前四位1011解析为年份，接下来两位24解析为月份——但24是无效月份，理论上应该报错，可能是你输入时的笔误？如果是'2010124-134523'这类，%Y取2010，%m取1（一位，合法月份），%d取24，就会正常解析。
• '20101124-34523'：时间部分少一位，%H取3（合法小时），%M取45，%S取23，数值合法所以不报错。
• '20101124-3453'：时间部分少两位，%H取3，%M取4，%S取53，数值都在合法范围内，正常解析。
• '20101124-343'：同理，%H取3，%M取4，%S取3，都是合法数值，不会报错。
• '01124-134523'：日期部分只有五位，%Y取0112（年份112），%m取4，但剩下的%d没有足够字符匹配，所以抛出ValueError。

如何实现严格的补零格式校验？ #

如果必须确保输入字符串严格符合YYYYMMDD-HHMMSS的补零格式（四位年、两位月、两位日、两位小时、两位分钟、两位秒），有两种靠谱的方法：

方法1：先做长度+正则校验，再解析

先检查字符串长度是否为15（YYYYMMDD是8位，加上-和HHMMSS的6位，总共15），再用正则表达式匹配严格的数字格式，最后再调用strptime：

import re
from datetime import datetime

def strict_parse_datetime(s):
    # 先检查长度是否正确
    if len(s) != 15:
        raise ValueError("输入字符串长度不符合YYYYMMDD-HHMMSS格式要求")
    # 正则匹配严格的数字格式
    if not re.fullmatch(r'\d{4}\d{2}\d{2}-\d{2}\d{2}\d{2}', s):
        raise ValueError("输入字符串不符合YYYYMMDD-HHMMSS的补零格式要求")
    # 最后解析为datetime对象
    return datetime.strptime(s, '%Y%m%d-%H%M%S')

# 测试用例
strict_parse_datetime('20101124-134523')  # 正常返回datetime对象
strict_parse_datetime('101124-134523')   # 抛出ValueError（长度不够）
strict_parse_datetime('20101124-34523')  # 抛出ValueError（长度不够）

方法2：解析后反向格式化对比

把解析出来的datetime对象重新格式化为%Y%m%d-%H%M%S字符串，和原字符串对比——如果不一致，说明原字符串不符合补零格式：

from datetime import datetime

def strict_parse_datetime(s):
    dt = datetime.strptime(s, '%Y%m%d-%H%M%S')
    # 将解析后的日期反向格式化为标准补零格式
    formatted_str = dt.strftime('%Y%m%d-%H%M%S')
    if formatted_str != s:
        raise ValueError("输入字符串不符合YYYYMMDD-HHMMSS的严格补零格式")
    return dt

# 测试用例
strict_parse_datetime('20101124-134523')  # 正常
strict_parse_datetime('2010124-134523')   # 抛出ValueError（格式化后是'20100124-134523'，和原串不一致）

这种方法的好处是不用写正则，还能自动覆盖所有格式的补零校验，比如月份1会被格式化为01，和原串的1对比就会触发错误，非常省心。

内容的提问来源于stack exchange，提问作者kbr85