$time_local 和 $time_iso8601 按用途分工：前者用于人工排查和本地运维看板，后者用于跨系统时间对齐与自动化分析；二者是同一时刻的两种表达，差异在于语义适配场景而非精度。
直接用 $time_local 和 $time_iso8601 并不是“选一个”，而是按用途分工：前者用于人工排查和本地运维看板，后者用于跨系统时间对齐与自动化分析。它们本质是同一时刻的两种表达，差异不在精度，而在语义适配场景。
区分用途：人工可读 vs 程序可解析
$time_local（如 19/June/2026:00:56:22 +0800）格式固定、带空格和斜杠，适合日志实时 tail 查看、ELK 中 Kibana 的 Discover 页面快速浏览；$time_iso8601（如 2026-06-19T00:56:22+08:00）符合 RFC 3339，能被 Logstash、Prometheus、Grafana、Python pandas 等工具原生识别，无需额外 grok 解析。
- 若监控告警依赖日志时间做滑动窗口统计（如“过去5分钟错误率”），必须用
$time_iso8601配合datefilter 归一化到@timestamp，否则时区混用会导致窗口错位 - 若 SRE 夜间值班需快速扫一眼 access.log 判断是否刚有流量突增，
$time_local更直观——不用心算 ISO 格式年月日
多时区业务中统一时间基准的关键操作
全球化部署下，Nginx 实例可能分布在东京、法兰克福、硅谷，$time_local 各自显示本地时间，但日志分析平台必须基于同一时间轴。此时不能依赖各节点的 $time_local 做聚合，而应：
- 在所有 Nginx 节点的
log_format中强制包含$time_iso8601，且确保系统时钟已用 NTP 同步（推荐 chrony + pool.ntp.org） - Logstash 或 Filebeat 的 pipeline 中，用
date插件显式指定timezone => "UTC"或真实源头时区（如"Asia/Tokyo"），将$time_iso8601解析为@timestamp—— 这一步不可省略，否则默认会按机器本地时区解释 - 避免用
$time_local反向推算 UTC：它只反映 Nginx 所在 OS 的TZ设置，若某台机器误配TZ=Asia/Shanghai但实际在新加坡机房，$time_local就已失真
兼容旧系统与审计追溯的双写策略
部分遗留 BI 工具或法务审计系统只认 Apache 风格日志格式（含 $time_local），此时可采用双字段输出，不牺牲任一需求：
log_format global_log '$time_iso8601|$time_local|$remote_addr|$request|$status|$body_bytes_sent|$request_time'; access_log /var/log/nginx/global.log global_log;
- 第一列
$time_iso8601供 ELK/Grafana 实时分析，支持毫秒级排序与跨集群 join - 第二列
$time_local保留原始上下文，当发现某条日志@timestamp异常时，可对照该字段快速定位是否为时钟漂移或解析配置错误 - 字段间用
|分隔，比空格更利于后续用 awk 或 log parser 提取，也规避了请求 URL 中空格导致的字段错位问题
注意 $msec 的协同使用场景
单靠 $time_iso8601 只有秒级精度，若需分析首字节延迟（TTFB）或微服务间调用耗时对齐，须叠加 $msec：
-
$msec是 Unix 时间戳带毫秒的小数（如1749985582.123），与$time_iso8601同步生成，代表请求头接收完成时刻 - 例如记录：
2026-06-19T00:56:22.123+08:00|1749985582.123|...，前者便于人读，后者便于程序做 sub-second 差值计算 - 不要用
$request_time替代——它是耗时，不是时间点；把它和$msec相加才能得到响应结束时刻
