time元素的datetime属性必须使用ISO 8601格式（如“2024-03-15”或“2024-03-15T14:30:00+08:00”），非标准格式会导致语义丢失；文字内容可本地化，但datetime必须机器可读且时区一致。
time 元素的 datetime 属性必须用 ISO 8601 格式
浏览器和搜索引擎只认标准格式，datetime 值写成 "2024-03-15" 或 "2024-03-15T14:30:00+08:00" 才会被正确解析；写成 "2024/03/15"、"15-03-2024" 或 "2024年3月15日" 会导致语义丢失，time 元素退化为普通容器。
常见错误场景：后端模板拼接时间时没做格式转换，或前端用 toLocaleDateString() 直接赋值给 datetime —— 这类字符串人类可读，但机器无法解析。
-
datetime值必须是完整日期（YYYY-MM-DD）或带时分秒及时区（YYYY-MM-DDTHH:MM:SS±HH:MM），不能省略前导零 - 纯日期场景（如文章发布日）用
YYYY-MM-DD足够；含具体时刻（如实时更新时间）建议补全时分秒和时区 - 若时间来自用户输入或本地 JS
Date对象，优先调用.toISOString()（返回 UTC）或.toISOString().replace('Z', '+00:00')避免隐式时区偏差
更新时间该放 time 元素里，还是仅用 span + aria-label？
如果目标是让屏幕阅读器、搜索引擎或未来 API（如 RSS 解析器）能明确识别“这是更新时间”，必须用 <time datetime="...">文字内容</time>。仅靠 <span aria-label="更新于 2024-03-15">3月15日</span> 是障眼法：aria-label 不参与结构化数据提取，Google Search Console 的富媒体搜索结果测试工具会直接忽略它。
实际使用中，文字内容（即 <time>...</time> 标签内的文本）可以按本地习惯写（如“3小时前”“昨天”），但 datetime 属性必须保持机器可读的绝对时间点。
立即学习“前端免费学习笔记（深入）”；
- 动态更新的时间（如“2分钟前”）需同时维护一个隐藏的
<time datetime="2024-03-15T14:28:00+08:00" aria-hidden="true"></time>，供机器读取 - 服务端渲染页面，推荐在 HTML 中直接写出
datetime和对应中文文案，避免首屏 JS 加载延迟导致语义缺失 - 不要为了“看起来简洁”而省略
datetime属性——没有它的<time></time>和<span></span>没本质区别
datetime 值用本地时间还是 UTC？
取决于内容属性：文章发布时间通常按发布系统所在地（如中国站点用 +08:00），而日志类更新时间（如“服务器最后同步时间”）建议统一用 UTC，避免跨时区协作时歧义。
关键不是选哪个“更正确”，而是保持站内一致。混用会导致聚合工具（如 CMS 时间线、SEO 工具排序）把同一天的更新识别成两天。
- 用
new Date().toISOString()得到的是 UTC，适合后端 API 返回或日志场景 - 用
new Date().toLocaleString('zh-CN', {timeZone: 'Asia/Shanghai'})配合手动构造 ISO 字符串，适合前端展示型更新时间 - Node.js 后端常用
date-fns-tz的formatInTimeZone(date, 'Asia/Shanghai', "yyyy-MM-dd'T'HH:mm:ssXXX")确保格式与时区可控
更新时间要不要加 pubdate 属性？
不要加。pubdate 是 HTML4 旧属性，在 HTML5 中已被废弃，所有现代浏览器都不支持，W3C 验证器会报错。替代方案是用 role="doc-published" 或 role="doc-modified"（配合 ARIA 1.2+）表达语义，但目前搜索引擎几乎不识别这些 role —— 所以最稳妥的做法，仍是靠 <time datetime></time> 自身的上下文（比如放在 <article></article> 底部、class 名为 post-meta__updated）来暗示用途。
真正影响 SEO 的，是 datetime 值是否真实、是否与页面内容强相关，而不是加了什么废弃属性或花哨 role。
容易被忽略的一点：更新时间的 datetime 值如果晚于当前服务器时间（比如误设为明天），可能被 Google 视为时间欺诈，影响收录时效性判断。
