time标签的datetime属性必须严格使用ISO 8601格式，如2024-03-15或2024-03-15T15:30:45Z，年月日需四位及两位补零，时区推荐显式标注，缺失或格式错误将导致机器无法解析。
time 标签的 datetime 属性必须用 ISO 8601 格式
浏览器和搜索引擎只认标准格式，写成 2024-3-15 或 下午3点 都会被忽略——datetime 不是给人看的，是给机器解析用的。
ISO 8601 要求年份 4 位、月份和日期都两位补零，时间部分可选但推荐带上时区。常见合法值：
-
2024-03-15（仅日期） -
2024-03-15T15:30（本地时间，无时区，部分解析器会默认为 UTC） -
2024-03-15T15:30:45Z（UTC 时间） -
2024-03-15T15:30:45+08:00（东八区时间）
不带 datetime 的 <time> 标签对机器无效
只写 <time>昨天</time> 或 <time>2024年3月15日</time>，视觉上能显示，但所有结构化数据提取工具（比如 Google 的 Rich Results Test）都读不到时间语义——datetime 是强制字段，不是可选装饰。
常见错误场景：
立即学习“前端免费学习笔记（深入）”；
- 用户手动拼接中文日期字符串，没设
datetime - 后端模板直接输出
<time>{{ post.date | date:"Y年m月d日" }}</time>，漏掉 ISO 格式属性 - JavaScript 动态插入
<time>时只更新 innerText，没同步设置datetime属性
时区处理不当会导致时间偏移
如果服务器生成的时间字符串没带时区（如 2024-03-15T15:30:00），不同浏览器可能按本地时区或 UTC 解析，结果不一致。Google Search Console 明确建议：显式标注时区。
实操建议：
- 服务端优先输出带
Z或+08:00的完整时间 - 前端用
new Date().toISOString()生成 UTC 时间（返回类似"2024-03-15T07:30:45.123Z"），去掉毫秒再用：new Date().toISOString().slice(0, 19) + "Z" - 避免用
toLocaleString()拼接，它输出的是本地格式，不是 ISO
SEO 和无障碍支持依赖 datetime 的正确性
Google 的结构化数据测试工具会校验 datetime 值是否可解析；屏幕阅读器也可能读出该属性值（取决于实现），但核心价值在于机器识别。
容易被忽略的细节：
-
datetime值不能含空格或中文标点（如2024/03/15或2024-03-15 15:30都非法） - 日期部分必须存在，时间部分可省略，但不能反过来（
T15:30单独出现不合法） - PHP 的
date("c")、Python 的datetime.isoformat()默认输出带毫秒或时区偏移，需截断或标准化
机器可读性的门槛很低，但错一个字符就全失效。别靠肉眼判断格式对不对，用 new Date("2024-03-15T15:30Z") 在控制台试一下，返回有效日期对象才算过关。
