HTML代码中time标签标注时间规范-html教程-PHP中文网

time标签的语义有效性取决于datetime属性是否为合法iso 8601字符串，必须静态、精确且与显示文本解耦，错误格式或动态修改将导致机器解析失败。

html代码中time标签标注时间规范

标签的语义有效性完全取决于 datetime 属性是否合法——不写、写错、动态塞进去，机器就当它不存在。

datetime 属性必须是 ISO 8601 字符串，不能是“看起来像日期”的文本

浏览器、爬虫、屏幕阅读器只读 datetime 的值，不是标签里写的中文或斜杠格式。常见错误包括：

datetime="2026/07/23"（斜杠非法）
datetime="2026-7-23"（月/日未补零）
datetime="2026-07-23 15:52"（缺 T 分隔符）
datetime="2026-07-23T15:52:00GMT+8"（非标准时区缩写）

正确写法只有这些：

datetime="2026-07-23"（纯日期）
datetime="2026-07-23T15:52:00+08:00"（带时区偏移，推荐）
datetime="2026-07-23T07:52:00Z"（UTC 时间）
datetime="PT2H30M"（持续时间，开头必须是 PT）

显示文本和 datetime 值必须解耦，但不能语义冲突

人看的可以写“刚刚”“发布会当天”，机器读的必须是确定时间点。关键在于：文本可变，datetime 必须静态且真实。

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

✅ 允许：<time datetime="2026-07-23T15:52:00+08:00">刚刚</time>
❌ 禁止：<time datetime="2026-07-23T15:52:00+08:00">刚刚</time> → 后续 JS 把 datetime 改成 "2026-07-23T15:52:05+08:00"（原始时间点丢失）
⚠️ 风险：datetime="2026-07-23" 却显示“昨天”，对屏幕阅读器用户构成误导

后端渲染时别用 toLocaleDateString() 拼接——它输出的是 "2026/7/23" 这类本地格式；应优先用 toISOString().slice(0, 19)（UTC）或 Intl.DateTimeFormat + formatToParts() 构造带偏移的合法字符串。

哪些场景不该用 time 标签

<time></time> 不是“所有含时间字样的内容都该套一层”的装饰工具，它是语义开关：开了就必须提供机器可验证的绝对时间点或明确时长。

❌ 营业时间：<time>9:00–18:00</time>（没绑定具体日期，无法解析为唯一时间点）
❌ 相对时间：<time datetime="2026-07-23T15:52:00+08:00">2小时后</time>（datetime 值固定，但“2小时后”随页面刷新失效）
❌ 年份范围：<time datetime="2020–2024">2020–2024</time>（ISO 不支持范围写法，应拆成两个 <time></time> 或放弃语义化）
❌ 混合元信息：<time>作者：张三｜发布时间：2026-07-23</time>（混入非时间字段，破坏结构）

JS 读取和验证 datetime 时的坑

el.dateTime 返回的是字符串，不是 Date 对象。直接传给 new Date() 容易因时区处理不一致出错。

Safari 对 2026-07-23T15:52（无秒、无时区）支持不稳定，建议统一写到秒级并带偏移：2026-07-23T15:52:00+08:00
new Date(t.dateTime) 在 Chrome 可能按本地解释，在 Safari 可能默认当 UTC —— 更稳妥的是：new Date(t.getAttribute('datetime'))
Google Search Console 只解析 HTML 初始源码，JS 动态插入的 datetime 会被忽略
验证方法：DevTools 里选中元素，看 DOM 中 datetime 是否存在、值是否为纯字符串（非空、无空格、无中文、无斜杠）

真正容易被忽略的点是：它不报错，页面照常显示，但 SEO 丢时间权重、RSS 聚合失败、iOS 分享卡片不显示时间——问题藏在看不见的地方。