标签必须带符合ISO 8601格式的datetime属性才具语义价值，否则仅作普通容器；正确写法如2025年3月15日，支持日期、时间及时区标注，适用于文章发布、活动时间等可被程序提取的场景。

用 标签必须带 datetime 属性才有效

浏览器和搜索引擎只认带 datetime 属性的 ，光写 2025年3月15日 是无效的——它不会被解析为机器可读的时间，辅助技术也读不出含义。

正确做法是：显式提供符合 ISO 8601 格式的 datetime 值，再把人类可读文本放在标签内。两者可以不同（比如显示“昨天”，但 datetime 写具体时间）。

• datetime 必须是合法格式：YYYY-MM-DD、HH:MM、YYYY-MM-DDTHH:MM:SSZ 等，不能用中文或口语化表达
• 不写 datetime 时， 仅作为普通内联容器，失去语义价值
• 日期部分缺失时（如只有时间），datetime 仍需补全：浏览器会按当前日期解释，但不推荐依赖此行为

datetime 常见格式与对应写法

ISO 8601 是唯一被广泛支持的标准，其他格式（如 2025/03/15 或 15-03-2025）会导致解析失败或被忽略。

2025年3月15日
下午2:30
3月15日 14:30（东八区）
3月15日 UTC 06:30

注意：Z 表示 UTC，+08:00 表示东八区；混用本地时间与 UTC 时，务必确认时区标注准确，否则机器解析结果会偏移。

哪些场景适合用 ，哪些不该硬套

的核心价值是「让时间可被程序提取」，不是为了视觉美化或替代 。

• ✅ 适合：文章发布时间、活动起止时间、倒计时目标时刻、版本更新日期、日志时间戳
• ❌ 不该用：纯装饰性数字（如“距今 3 天”未绑定真实时间点）、模糊表述（“下周二”、“春节前”）、非时间类数字（“第5期”、“版本2.1”）
• ⚠️ 警惕：CMS 自动生成的日期若没输出 datetime 属性，加了 标签也没意义

兼容性与实际效果别太乐观

目前主流浏览器都支持 渲染，但「支持」不等于「有用」：

• 屏幕阅读器对 的播报策略不统一：有的读 datetime，有的读标签内文本，有的两者都读
• 搜索引擎会索引 datetime，但不会因此提升排名；真正影响 SEO 的仍是内容质量和结构化数据（如 JSON-LD）
• 想确保时间被正确理解，最好额外加上 aria-label 或用 meta 提供结构化数据

最常被忽略的一点：很多人以为加了 就自动适配本地时区，其实它只是标记，不触发任何转换逻辑——时区换算、相对时间（如“2小时前”）仍需 JS 完成。