pd.date_range() 日期数不符的根本原因是freq参数定义时间点推演规则而非固定天数间隔，如'd'为日历日、'b'为工作日、'ms'为每月1号，错误使用'7d'等会导致对齐偏差和数量减少。
pd.date_range() 为什么生成的日期数和预期对不上
根本原因在于 freq 参数不是“间隔多少天”，而是“按什么规则推演时间点”——比如 'D' 是日历日，'B' 是工作日，'MS' 是每月1号。很多人用 freq='7D' 想得到每周一，结果发现首尾日期偏移、总数变少。
- 默认
freq='D'包含所有日历日，周末也算；要跳过周末必须显式写'B'或'W-MON' -
periods和end同时指定时，end是“最多不超过”，实际可能少一天（尤其遇到频率不整除） - 用
freq='M'得到的是每月最后一天，不是自然月；要每月1号得用'MS'（Month Start）
如何让 date_range() 严格按自然周/自然月对齐
关键在选对频率别名，而不是靠手动加减。比如“从 2024-01-01 开始，取连续5个自然周，每周日结束”，不能用 freq='7D'，因为 2024-01-01 是周一，+7D 是下周一，不是周日。
- 自然周：用
'W-SUN'（周日为一周结束）或'W-MON'（周一为结束），配合closed='left'控制端点 - 自然月：用
'MS'（每月1号）或'M'（每月最后一天），别用'30D'—— 二月会出错 - 季度对齐：用
'QS-JAN'（每年1月1日开始的季度）比'90D'可靠得多
示例：pd.date_range('2024-01-01', periods=3, freq='MS') → DatetimeIndex(['2024-01-01', '2024-02-01', '2024-03-01'])
freq 参数里那些容易混淆的缩写
官方文档缩写表看着全，但日常就几个高频且易错：
-
'BM'= Business Month end（当月最后一个工作日），不是'M'的工作日版；'BMS'才是“当月第一个工作日” -
'W'默认以周日为一周结束，'W-FRI'才是以周五结束；写'W'却想周五对齐，结果全错位 -
'H'是小时，但'BH'是工作小时（只算工作日的 9–17 点？错——'BH'只保证在工作日，不控制具体小时段） -
'QS'和'BQS'差在是否跳过非工作日起点：前者固定 1/4/7/10 月1号，后者会把 1月1日是周六的情况挪到1月2日（如果2号是工作日）
时区与夏令时带来的隐性偏差
加了 tz 后，date_range() 不再只是数学推演，而是走真实时钟逻辑。比如 freq='D' 在夏令时切换日可能生成23或25小时的“天”。
- 纽约时区 2024-11-03 凌晨2点回拨，
freq='D'在那天会重复生成一次 1:00–2:00 区间（本地时间） - 用
tz='UTC'最稳，但业务数据常需本地时区；此时建议优先用freq='24H'（固定24小时）替代'D'，避免歧义 -
normalize=True会强制当天0点，但遇上 DST 切换日，可能把某天“抹掉”或“多出”一个时间点
真正难处理的不是语法，是当你把 freq='W' 和 tz='Europe/London' 一起用，又没意识到英国夏令时在3月最后一个周日切换——那天的 range 可能少一小时，也可能多一小时，而报错不会告诉你原因。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
