datetime 属性是 元素的语义核心，必须为标准 iso 8601 格式（如 2024-05-20t14:30:00+08:00），不可用本地化文本或手拼字符串；缺失或错误将导致辅助技术、搜索引擎等无法识别时间信息。
datetime 属性不是“可选格式化开关”，而是 <time></time> 元素的语义命脉——不写、写错、或写得不标准，<time></time> 就退化为普通 <span></span>，所有辅助技术、搜索引擎结构化数据提取、日历工具都收不到时间信号。
datetime 必须是 ISO 8601 字符串，不能是本地化文本
常见错误是把人类可读内容直接塞进 datetime：比如 <time datetime="2024年5月20日">2024年5月20日</time> 或 <time datetime="昨天">昨天</time>。这些值浏览器不会报错，但 document.querySelector('time').dateTime 会返回空字符串，Google Rich Results Test 也会提示 “Missing field ‘datePublished’”。
合法值只接受机器无歧义解析的 ISO 格式：
-
2024-05-20（纯日期，年月日必须补零） -
14:30（仅时间，需上下文明确日期） -
2024-05-20T14:30:00+08:00（推荐：T 不可省略，时区偏移必须含±HH:MM） -
2024-05-20T06:30Z（UTC 时间，Z是字面量，不能写成+00:00以外的等效形式）
非法写法包括：2024/05/20、2024-5-20、2024-05-20 14:30、2024-05-20T14:30+8、GMT+8。
前端 JS 动态生成 datetime 时，优先用 toISOString()
用 new Date().toString() 或 .toLocaleString() 拼接 datetime 是高危操作——它们输出非标准格式，且隐含本地时区，无法被解析。
安全做法：
- 要 UTC 时间：直接用
date.toISOString()（返回类似"2026-04-29T07:41:22.123Z"） - 要本地时区带偏移：别手动拼，改用
Intl.DateTimeFormat配{ format: "extended" }，或第三方库如date-fns/formatISO(date, { format: "extended" }) - 绝对不要用
date.getFullYear() + "-" + (date.getMonth()+1)这类手拼逻辑——漏补零、时区错位、夏令时翻车全在里头
不带时区的 datetime 值默认行为不可靠
写 <time datetime="2024-05-20T14:30"></time> 理论上表示“本地时间”，但 W3C 并未定义“本地”是谁的本地：是服务器？用户设备？还是渲染时所在 UA？实际中 Chrome、Safari、NVDA 解析结果可能不一致。
实操建议：
- 服务端渲染优先输出带时区的完整格式，例如 Python 的
dt.isoformat()、Django 的{{ obj.time|date:"c" }} - 纯静态页若确定全站用户同属一个时区（如企业内网），可省略时区，但必须文档注明，且禁止拿它做跨时区计算
- 动态更新的时间（如“2分钟前”），仍需保留一个隐藏的
<time datetime="2026-04-29T15:39:00+08:00" aria-hidden="true"></time>供机器读取
没加 datetime 的 time 标签等于没写
<time>发布于昨天</time> 对人友好，对机器无效。屏幕阅读器只会朗读“发布于昨天”，不会转成具体日期；Google 不会从中提取 datePublished；日历工具无法订阅。
HTML5 规范明确要求：只要 <time></time> 内容是人类可读时间表述，就必须提供 datetime 属性。例外仅有一种：内容本身已是标准 ISO 格式且与属性值完全一致（如 <time datetime="2024-05-20">2024-05-20</time>），但这种写法维护性差，不推荐。
真正难的从来不是格式怎么写，而是判断这个时间值是否真的值得暴露给机器——比如“预计送达：30 分钟后”，填哪个绝对时间点才合理？硬填当前时间，反而造成语义污染。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
