$time_iso8601更通用，适合日志解析、跨系统对接和时序分析；$time_local仅适用于人工快速浏览。前者符合iso 8601标准，格式为2025-05-09t15:28:33+0800，后者为09/may/2025:15:28:33 +0800，含英文月份且结构不规范。
直接说结论：$time_iso8601 更通用，尤其在日志解析、跨系统对接、时序分析等场景中优势明显；$time_local 适合人工快速浏览，但对程序处理不友好。
两种变量的格式与本质区别
$time_local 和 $time_iso8601 都是 Nginx 内置时间变量，但底层标准和结构完全不同：
- $time_local：按本地时区输出，格式为 09/May/2025:15:28:33 +0800（Common Log Format），含英文月份缩写、日/月/年顺序颠倒、带空格与冒号混排，不符合机器可读规范；
- $time_iso8601：严格遵循 ISO 8601 国际标准，格式为 2025-05-09T15:28:33+0800，年月日有序、分隔符统一、含 T 字符明确区分日期与时间，天然支持时区偏移解析。
为什么 $time_iso8601 更易被下游系统识别
多数现代日志处理链路（如 Logstash、Fluentd、Flink、Elasticsearch、Prometheus exporters）默认内置对 ISO 8601 的解析能力：
- Logstash 的
date过滤器直接支持match => ["timestamp", "ISO8601"]，无需额外正则； - Elasticsearch 的
date字段类型能自动识别2025-05-09T15:28:33+0800并转为 UTC 时间戳； - Java 中
Instant.parse()或OffsetDateTime.parse()可直接解析该格式，而 $time_local 需先做字符串清洗和模式匹配； - 前端 JavaScript 的
new Date("2025-05-09T15:28:33+0800")能正确构造对象，但new Date("09/May/2025:15:28:33 +0800")会返回 Invalid Date。
何时可以考虑用 $time_local
并非完全弃用 $time_local，它仍有适用场景：
- 运维人员临时查日志，一眼看出“几号几时”，比看 “2025-05-09T” 更直观；
- 旧系统或嵌入式设备日志采集器只认 CLF 格式，且无法升级解析逻辑；
- 配合
log_format做简单审计日志，不涉及后续聚合分析。
推荐实践：用 $time_iso8601 为基础，按需重组格式
若业务要求显示为 “2025-05-09 15:28:33” 这类无 T、无时区符号的格式，不建议放弃 $time_iso8601，而是用 Nginx 的 map 指令安全提取重组：
- 在
http块中定义：map $time_iso8601 $log_time {<br> default "";<br> "~^(?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2})T(?<h>\d{2}):(?<i>\d{2}):(?<s>\d{2})" "$y-$m-$d $h:$i:$s";<br>}</s></i></h></d></m></y> - 再在
log_format中使用$log_time，既保持源头标准，又满足展示需求； - 避免在每个
server块里写if + set，减少性能开销与配置冗余。
