针对api.weather.com夏令时切换日的请求异常，可按以下方式处理：

核心原因 #

夏令时切换当天，当地时区的日期会出现23小时（启用夏令时）或25小时（停用夏令时）的异常情况，而API的日期参数大概率是基于UTC时区索引数据的，直接用当地日期请求会导致匹配不到完整数据或请求无效。

具体解决方法 #

1. 用UTC日期替代当地日期请求 #

将请求中的startDate和endDate替换为对应当地日期覆盖的UTC日期范围：

• 比如KALB所属的美国东部时区，夏令时启用当天（当地日期D）对应的UTC时间会跨D和D+1两天，因此请求时要包含这两个UTC日期：

  https://api.weather.com/v1/location/KALB:9:US/observations/historical.json?apiKey=<MY_API_KEY>&units=e&startDate=20260308&endDate=20260309
  

  之后从返回结果中筛选出当地时区属于目标日期（2026-03-08）的逐小时数据即可。

2. 避免单独请求切换日 #

不要单独请求夏令时切换的当地日期（比如startDate=20260307），而是请求包含该日期的连续UTC日期范围，确保覆盖当地切换日的所有UTC时间段。

3. 尝试时间戳参数（如果支持） #

如果API接受时间戳格式，可直接传入目标时间段的UTC秒级时间戳，比如：

https://api.weather.com/v1/location/KALB:9:US/observations/historical.json?apiKey=<MY_API_KEY>&units=e&startTime=1741584000&endTime=1741670399

注：上述时间戳对应UTC 2026-03-07 00:00:00到2026-03-07 23:59:59，可根据当地切换日的实际UTC区间调整。

针对你提到的范围请求问题 #

你用startDate=20260306&endDate=20260308请求时缺失3月7日数据，是因为该日期是夏令时切换日，其对应的UTC时间超出了你请求的日期范围，调整为覆盖切换日UTC区间的日期范围即可解决。

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