Claude Microsoft 365连接器的影响时间与公告时间怎样用Python区分

先把三个时刻放到同一时区

适用环境为macOS或Linux终端中的Python 3.12，无需额外依赖。代码中的三个输入均来自该事故的解决记录：影响开始、影响结束及解决消息发布时间。它们不是需要用户猜测或填写的示例日期。

python3 - <<'PY'
from datetime import datetime
from zoneinfo import ZoneInfo

# Anthropic在此事故解决说明中给出的UTC影响时间及发布时刻。
impact_start = datetime.fromisoformat('2026-11-12T16:03:00+00:00')
impact_end = datetime.fromisoformat('2026-11-13T16:40:00+00:00')
notice_time = datetime.fromisoformat('2026-11-13T21:49:44.029+00:00')
for name, value in [('影响开始', impact_start), ('影响结束', impact_end), ('解决公告发布', notice_time)]:
    print(name, value.astimezone(ZoneInfo('Asia/Shanghai')).isoformat())
print('公告列出的影响窗口:', impact_end - impact_start)
print('影响结束至解决公告发布:', notice_time - impact_end)
PY

预期北京时间输出为11月13日00:03开始、11月14日00:40结束，解决公告发布于11月14日05:49:44.029。按这些已知值计算，公告列出的影响窗口为24小时37分钟，影响结束到公告发布相隔5小时9分44.029秒。这里计算的是该份说明描述的时间关系，不是对每个账号影响时长的测量。

为什么最早调查时间又是另一回事

公开调查消息说明供应商何时向外报告问题，并不自动等于实际故障起点。解决记录可能在事后补充更早的影响开始时间。把首条调查的时间、影响区间和最后一条解决公告都称为“故障发生时间”，会丢掉它们各自的含义。

此次解决说明描述，从UTC时间11月12日16:03到11月13日16:40，连接器及Claude for Outlook中的邮件、日历和搜索工具，对许多请求返回错误。它没有声称这段时间里所有用户的所有请求都失败。

恢复迹象不能被时间换算成完全恢复

较早的监控更新发表于北京时间11月13日23:40。当时连接器和Claude for Outlook出现恢复迹象，但部分SharePoint搜索仍返回错误，微软事件也仍开放。时间换算只改变显示时区，不会改变这条消息的确定程度。

后续事件虽然被标记为已解决，解决说明仍提到微软正在完成恢复，可能有偶发错误或延迟。不能把旧监控消息改写成当时已经全部恢复，也不能在引用后续解决状态时删除其明确保留的限制。

这些时间不能代替业务回执

某项邮箱或日历任务恰好发生在影响区间内，并不足以证明它一定失败；任务位于区间外，也不代表所有后续动作必然成功。对具体操作，仍需要对应任务返回和实际业务记录。

同样，模型在工具报错后给出的解释文字，不能证明资料不存在，也不能证明一次写入已经完成。时间线能帮助定位问题，却不能单独成为批量重新发送、创建会议或修改日历的依据。