为什么先采集时区元数据
所有时间戳的换算方向都由主机的时区配置决定，因此时区元数据要在分析开始前采集，并与其他证据一起归档。它包含三部分：主机当前时区设置、硬件时钟是否使用 UTC、以及时间同步服务是否正常工作。缺少这份元数据时，日志里的时间只能靠猜，后续无论怎么修正都缺少依据。虚拟机与容器还要单独确认，因为它们经常与宿主机使用不同的时区。
基本信息
| Linux 采集项 | readlink -f /etc/localtime、/etc/timezone、timedatectl 输出 |
|---|---|
| Windows 采集项 | tzutil /g、Get-TimeZone、注册表 TimeZoneInformation 键、w32tm /tz |
| 网络设备 | Cisco show clock detail、华为 VRP display clock，注意输出中的时区字段 |
| 容器 | TZ 环境变量、容器内 /etc/localtime 是文件还是挂载点 |
| 同步状态 | chronyc tracking、timedatectl 的 NTP 行、w32tm /query /status |
| 记录要求 | 连同采集时刻与命令原文一起归档，作为报告附录 |
典型使用场景
- 把本地时间的日志换算到 UTC 前，确认原始时区与夏令时规则
- 核对容器日志与宿主机日志的时间差是否为固定时区偏移
- 判断硬件时钟设置是否影响开机阶段日志的时间
- 确认时间同步是否正常，决定是否需要额外的偏移评估
- 多主机合并前逐台采集，避免用同一套换算规则套用全部主机
- 为时间线报告写明换算说明，支撑结论可复核
两侧采集
两侧采集
# Linux：时区文件指向、时区名与硬件时钟设置
readlink -f /etc/localtime
cat /etc/timezone 2>/dev/null
timedatectl | sed -n '1,8p'
# 容器内同样取一遍，并与宿主机结果对照
cat /etc/timezone 2>/dev/null; echo "$TZ"; readlink -f /etc/localtime
# NTP 同步状态
chronyc tracking | sed -n '1,4p'
# Windows（PowerShell 或 cmd）
# Get-TimeZone ; tzutil /g ; w32tm /tz ; w32tm /query /status
# 注册表方式查看：HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
# 关注 Bias / ActiveTimeBias（单位分钟）、TimeZoneKeyName、DaylightBias采集项逐条读法
| 项目 | 含义 | 判读要点 |
|---|---|---|
| /etc/localtime | 本地时区文件，通常是指向 zoneinfo 的链接 | 链接目标决定时区名；直接是普通文件时无法从此判断时区名 |
| /etc/timezone | Debian 系保存的时区名 | 部分发行版无此文件，缺失不代表时区未配置 |
| timedatectl 输出 | 本地时间、UTC 时间、RTC 设置与时区名 | RTC in local TZ 为 yes 时，硬件时钟时间不等于 UTC |
| 注册表 Bias | 与 UTC 的偏移量，单位为分钟 | UTC = 本地时间 + Bias，符号容易看反 |
| DaylightBias | 夏令时期间附加偏移 | 启用夏令时的地区必须一并记录 |
| 同步状态 | 是否与时间源同步及差值 | 未同步的主机需要额外的偏移测量与修正 |
采集时把 NTP 或时间服务状态一并记下：时间同步异常的主机，日志时间需要额外的偏移评估，不能直接按配置的时区换算就完事。
容器与宿主机的时区经常不一致：容器默认可能使用 UTC，而宿主机使用本地时区。取容器日志时把两边都记一遍，换算方向才不会写反。