time标签的datetime属性必须严格使用ISO 8601格式，如2024-05-20或2024-05-20T14:30+08:00；斜杠、中文、缺T等均非法；文本内容可人性化，但须与datetime语义一致；不支持年份范围、相对时间等模糊表达；JS解析时需注意时区陷阱。
time 标签本身不定义格式规范，它只负责语义化地包裹时间/日期内容，并通过 datetime 属性提供机器可读的标准化值。浏览器不渲染该属性，但搜索引擎、屏幕阅读器和脚本依赖它——格式错，语义就失效。
datetime 属性必须用 ISO 8601 格式，不能自由发挥
这是硬性要求，不是建议。datetime 的值必须严格匹配 W3C 规定的 ISO 8601 子集，否则会被忽略或解析失败。常见错误是直接写中文日期、斜杠分隔、或带空格的“2024-05-20 14:30”。
-
2024-05-20✅ 纯日期（年-月-日） -
2024-05-20T14:30✅ 本地时间（T 不可省略） -
2024-05-20T14:30:22+08:00✅ 带时区偏移（推荐） -
2024-05-20T06:30Z✅ UTC 时间（Z 表示零时区） -
2024/05/20❌ 斜杠分隔，不合法 -
2024年5月20日❌ 中文，完全无效 -
2024-05-20 14:30❌ 缺少 T，解析失败
显示文本可以人性化，但别和 datetime 冲突
标签内文本（即用户看到的内容）可以任意格式，比如“昨天下午 2:30”或“五月二十日”，但前提是 datetime 属性仍保持 ISO 格式。两者语义需逻辑一致，否则会误导辅助技术或数据抽取工具。
注意：datetime 值应真实对应事件发生时间，不能为了“看起来像昨天”而动态改写——那得用 JS 更新整个 time 元素，而不是靠静态 HTML 欺骗。
time 标签不支持年份范围、时段或模糊时间的原生表达
HTML5 没有定义如 “2020–2024” 或 “约 3 小时后” 的标准 datetime 写法。遇到这些场景，只能退回到语义妥协方案：
- 年份范围：用两个
time标签分别标记起止，或放弃datetime，仅保留可读文本 - 相对时间（如“2 小时后”）：无法用
datetime表达，必须靠 JS 动态计算并更新datetime和文本 - 模糊时间（如“某天上午”）：W3C 明确不支持，
datetime只能填占位值如2024-01-01T09:00并加注释说明，但语义已降级
JS 读取和验证 datetime 时要注意时区陷阱
DOM 中获取 time.dateTime 返回的是字符串，不是 Date 对象。直接传给 new Date() 可能因浏览器实现差异导致时区误判（尤其没带时区信息的 2024-05-20T14:30）。
const el = document.querySelector('time');
const dtStr = el.dateTime; // "2024-05-20T14:30+08:00"
const date = new Date(dtStr); // ✅ 安全，含时区
// 但如果是 "2024-05-20T14:30" —— 这个值在 Chrome 当作本地时区，在 Safari 可能当 UTC
稳妥做法：强制补全时区（如拼上 +00:00），或用 Intl.DateTimeFormat 解析，避免依赖 Date 构造函数的隐式行为。
真正容易被忽略的，是 datetime 值一旦写死，就和页面其他逻辑脱钩；而时间类内容往往需要动态刷新。别指望一个静态 time 标签能自动同步服务器时间或响应用户时区切换。
