云日志默认多是 UTC
云平台的审计与访问日志普遍以 UTC 记录，例如 CloudTrail 的 eventTime 采用带 Z 后缀的 ISO 时间戳。把这类日志下载到本地后，直接当作本地时间读会让整条时间线偏移一个时区，而这种偏移往往很难在事后发现，因为它落在合理的时间范围内。
同一平台内也不统一
同一个云厂商的不同日志，字段时区未必相同：审计日志的 eventTime 是 UTC，对象存储访问日志的时间字段带明确的时区偏移，虚拟私有网络的流日志又常用 Unix 秒。跨平台合并前，必须逐平台、逐日志类型核对字段定义，并在转换脚本里显式注明。
基本信息
| 适用平台 | AWS、阿里云、腾讯云、Azure 等平台的审计与访问日志 |
|---|---|
| 典型 UTC 字段 | CloudTrail eventTime（带 Z）、CloudWatch 日志条目时间 |
| 需按文档确认 | 对象存储访问日志、负载均衡访问日志的时间字段 |
| 常见其他形式 | VPC 流日志的 Unix 秒、CDN 日志的本地时间字符串 |
| 对齐做法 | 解析时保留原始偏移，再统一转 UTC 入库 |
典型使用场景
- 确认某次 API 调用是否发生在事件窗口内：先核对字段时区再比较
- 把云审计与主机日志合并成时间线：统一转 UTC 后才做关联
- 排查异常登录：用审计日志的源地址与时间对上主机侧认证记录
- 跨区域事件分析：不同区域日志都用 UTC，可直接比较
- 证据说明：在报告里写明每个来源的时区与转换方式
先核对一个样本
先核对一个样本
# 看审计日志里时间字段的实际写法
zcat logs.json.gz | head -1 | python3 -m json.tool | grep -m1 eventTime
# 明确按 UTC 解析并转成本地时间显示，便于对照业务时间
date -u -d '2026-01-02T03:20:11Z' '+%F %T %Z'
TZ=Asia/Shanghai date -d '2026-01-02T03:20:11Z' '+%F %T %Z'
# 对象存储访问日志一般带偏移，直接按原样解析
# head -3 access.log常见字段时区速查
| 来源 | 字段 | 时区 |
|---|---|---|
| 云审计日志 | eventTime | UTC（带 Z 后缀） |
| 对象存储访问日志 | 请求时间字段 | 带偏移，需按文档确认 |
| VPC 流日志 | start / end | 常为 Unix 秒（UTC） |
| 云主机系统日志 | syslog 时间 | 取决于实例时区配置 |
| 负载均衡访问日志 | time 字段 | 多为 UTC，仍以文档为准 |
云平台日志的存储时间（对象 LastModified）只表示文件写入对象存储的时刻，不等于日志内事件的时刻，两者相差可能是数分钟到数小时。
跨平台合并时建议在中间数据里保留一列原始时间字符串与一列统一后的 UTC 时间，出现争议时可以回到原始写法复核。