time元素仅语义化标记，datetime属性值必须严格符合iso 8601标准，如2024-05-20或2024-05-20t14:30:00+08:00；非法格式（如中文、斜杠分隔、小写z）将导致语义丢失。
HTML 的 time 元素本身不处理时间格式解析或校验，它只负责语义化标记——真正起作用的是你传给它的 datetime 属性值，必须严格符合 ISO 8601 标准，否则搜索引擎、屏幕阅读器和浏览器扩展可能无法识别或解析错误。
datetime 属性必须用 ISO 8601 格式，不能写中文或自定义格式
常见错误是直接写 <time datetime="2024年5月20日">2024年5月20日</time> 或 <time datetime="2024/05/20">…</time>。这些都不合法，datetime 属性值会被浏览器忽略（DevTools 中可见该属性存在但无语义含义）。
合法写法只接受以下形式：
-
YYYY-MM-DD（如2024-05-20）→ 表示日期 -
HH:MM或HH:MM:SS（如14:30、09:15:22）→ 必须搭配日期使用，单独用无效 -
YYYY-MM-DDTHH:MM（如2024-05-20T14:30）→ 推荐，含时区信息更佳 -
YYYY-MM-DDTHH:MM:SS±HH:MM（如2024-05-20T14:30:00+08:00）→ 显式声明时区，避免歧义
注意：T 是字面量，不可省略或替换成空格；±HH:MM 时区偏移不能写成 +8 或 GMT+8。
不带时区的 datetime 值默认视为本地时间，但实际行为不可靠
如果你写 <time datetime="2024-05-20T14:30">…</time>，W3C 规范说这表示“本地时间”，但问题在于：哪个本地？用户设备系统时区？服务器时区？没有明确定义，不同 UA 解析可能不一致。
实操建议：
- 服务端生成时，优先输出带时区的完整格式，比如 Python 的
dt.isoformat()默认带+00:00，Django 的{{ obj.pub_time|date:"c" }}也输出标准 ISO 格式 - 前端 JS 动态插入时，用
new Date().toISOString()（始终返回 UTC），再根据业务需要手动补偏移（不推荐直接用.toString()，它返回本地字符串，非标准格式） - 纯静态页面若确定所有用户都在同一时区（如企业内网），可省略时区，但需文档注明，且不能依赖其做跨时区计算
datetime 属性为空、无效或缺失时，time 元素会退化为普通内联容器
浏览器不会报错，但语义丢失。你可以通过 DevTools 查看元素是否被识别为有效时间节点：右键检查 → 在 Elements 面板中观察 time 元素是否被辅助技术或结构化数据工具（如 Google Rich Results Test）提取到。
验证方法：
- 打开 Chrome DevTools → Console 输入
document.querySelector('time').dateTime，返回""或null表示无效 - 在 Google Rich Results Test 中粘贴 HTML，看是否识别出
datePublished等字段 - 避免用 JavaScript 动态设置
elem.setAttribute('datetime', '...')后忘记触发重新解析（其实无需触发，但值必须合法）
最易被忽略的一点：即使格式肉眼看着“差不多”，比如 2024-05-20T14:30:00Z（合法）和 2024-05-20T14:30:00z（小写 z，非法），也会导致整个属性失效。大小写、分隔符、冒号缺一不可。
