datetime属性是time标签唯一被机器识别的时间数据源，必须严格符合ISO 8601格式（如2026-08-04或2026-08-04T19:00:00+08:00），显示文本可与之不同，但不可用中文、斜杠或缺前导零等非标准写法。
datetime属性是
它不是装饰性字段，而是唯一被搜索引擎、爬虫、屏幕阅读器和 JS 解析器识别的时间数据源。没有 datetime 属性的 <time> 标签，和普通 <span> 没区别——显示正常，但语义完全丢失。
常见错误现象：<time>昨天</time>、<time>2026/08/04</time>、<time>八月四日</time>。这些写法在页面上看起来没问题，但 Google Search Console 会跳过该节点，JS 调用 el.getAttribute('datetime') 返回 null，NVDA/VoiceOver 也不会将其归类为时间实体。
datetime值必须严格符合ISO 8601，错一个字符就解析失败
浏览器不报错，但所有下游工具（包括 new Date()）可能返回 Invalid Date 或静默忽略。关键不是“像不像日期”，而是能否被无歧义解析。
-
2026-08-04✅（仅日期，合法） -
2026-8-4❌（缺前导零，Safari/IE 可能失败） -
2026/08/04❌（斜杠非 ISO 标准） -
2026-08-04T00:00:00⚠️（无时区，JS 解析结果依赖用户本地设置） -
2026-08-04T00:00:00+08:00✅（推荐，显式时区） -
2026-08-04T16:30:00Z✅（UTC 时间，末尾必须大写Z）
显示文本和datetime值可以完全不同，这是设计本意
很多人卡在这里：以为两者必须一致。其实 datetime 是给机器读的，标签内文本是给人看的。二者职责分离，互不干扰。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
正确示例：
<time datetime="2026-08-04T00:54:00+08:00">刚刚</time><br><time datetime="2026-08-04">今天</time><br><time datetime="2026-09-10T19:00:00+08:00">下周三晚七点</time>
错误做法：
- 把相对时间塞进
datetime，如datetime="刚刚"—— 所有解析器当无效值丢弃 - 用中文或缩写写时区，如
datetime="2026-08-04T19:00:00GMT+8"—— 非 ISO 格式，爬虫不认 - 后端模板里直接拼
toLocaleDateString()结果赋给datetime—— 输出格式不可控，大概率不合规
JS读取datetime要绕开IE兼容性和时区陷阱
直接写 el.dateTime 在 IE 中是 undefined；只传日期字符串（如 "2026-08-04"）给 new Date()，Safari 可能按 UTC 解析，Chrome 按本地时区，结果不一致。
稳妥读取方式：
- 统一用
el.getAttribute('datetime')获取原始字符串 - 若只有日期，手动补
T00:00:00和本地时区偏移（new Date().getTimezoneOffset()计算） - 若含时区（如
+08:00或Z），可直接传给new Date() - 始终校验结果：
!isNaN(new Date(dtStr).getTime())
容易被忽略的一点：datetime 值一旦写死在 HTML 中，就不能靠 JS 后续动态改——爬虫只抓初始 HTML，改了也没用。需要动态时间，得在服务端渲染时就生成合规字符串，而不是等页面加载完再塞值。
