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

用 标签必须带 datetime 属性才有效
浏览器和搜索引擎只认带 datetime 属性的 ,光写 是无效的——它不会被解析为机器可读的时间,辅助技术也读不出含义。
正确做法是:显式提供符合 ISO 8601 格式的 datetime 值,再把人类可读文本放在标签内。两者可以不同(比如显示“昨天”,但 datetime 写具体时间)。
-
datetime必须是合法格式:YYYY-MM-DD、HH:MM、YYYY-MM-DDTHH:MM:SSZ等,不能用中文或口语化表达 - 不写
datetime时,仅作为普通内联容器,失去语义价值 - 日期部分缺失时(如只有时间),
datetime仍需补全:浏览器会按当前日期解释,但不推荐依赖此行为
datetime 常见格式与对应写法
ISO 8601 是唯一被广泛支持的标准,其他格式(如 2024/03/15 或 15-03-2024)会导致解析失败或被忽略。
注意:Z 表示 UTC,+08:00 表示东八区;混用本地时间与 UTC 时,务必确认时区标注准确,否则机器解析结果会偏移。
立即学习“前端免费学习笔记(深入)”;
哪些场景适合用 ,哪些不该硬套
的核心价值是「让时间可被程序提取」,不是为了视觉美化或替代 。
- ✅ 适合:文章发布时间、活动起止时间、倒计时目标时刻、版本更新日期、日志时间戳
- ❌ 不该用:纯装饰性数字(如“距今 3 天”未绑定真实时间点)、模糊表述(“下周二”、“春节前”)、非时间类数字(“第5期”、“版本2.1”)
- ⚠️ 警惕:CMS 自动生成的日期若没输出
datetime属性,加了标签也没意义
兼容性与实际效果别太乐观
目前主流浏览器都支持 渲染,但「支持」不等于「有用」:
- 屏幕阅读器对
的播报策略不统一:有的读datetime,有的读标签内文本,有的两者都读 - 搜索引擎会索引
datetime,但不会因此提升排名;真正影响 SEO 的仍是内容质量和结构化数据(如 JSON-LD) - 想确保时间被正确理解,最好额外加上
aria-label或用meta提供结构化数据
最常被忽略的一点:很多人以为加了 就自动适配本地时区,其实它只是标记,不触发任何转换逻辑——时区换算、相对时间(如“2小时前”)仍需 JS 完成。











