<time> 标签必须包含符合 ISO 8601 标准的 datetime 属性，如 datetime="2024-03-15" 或 datetime="2024-03-15T14:30:00+08:00"，不可用中文、斜杠或空格；标签内文本供人阅读，可与 datetime 不同，但需语义一致；仅在需机器解析、排序、无障碍访问等场景使用。
time 标签的正确写法和 datetime 属性必须填什么
<time> 不是装饰性标签，浏览器和屏幕阅读器会依赖 datetime 属性解析真实时间。不写 datetime，或写错格式，等于没标——比如 <time>2024年3月15日</time> 对机器完全无意义。
必须用机器可解析的 ISO 8601 格式：
-
datetime="2024-03-15"（仅日期） -
datetime="2024-03-15T14:30"（带时间，时区默认本地） -
datetime="2024-03-15T14:30:00+08:00"（显式带时区，推荐） - 不能用中文、斜杠分隔、空格代替
T，例如"2024/03/15"或"2024-03-15 14:30"都无效
显示内容可以和 datetime 不一致，但别误导用户
标签内文本是给人看的，datetime 是给机器读的，二者可以不同——这是它的核心价值。比如：
<time datetime="2024-03-15T09:00:00+08:00">今天上午9点</time>
但要注意边界：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 避免语义冲突：比如
datetime="2024-03-15"却显示“昨天”，对屏幕阅读器用户就是错误信息 - 避免过度简化：显示“刚发布”这种模糊表述可以，但若全文多处都这么写，就失去结构化时间的意义
- 多语言站点中，
datetime仍必须是 ISO 格式，不可随 locale 变化
哪些场景真该用 time，哪些纯属画蛇添足
不是所有时间都要套 <time>。它只在需要被程序提取、排序、聚合、无障碍访问时才有价值。
- ✅ 应该用：文章发布时间、活动开始时间、订单创建时间、博客归档列表中的日期
- ✅ 应该用：API 返回的时间字段做前端渲染（配合 JS 处理相对时间时，保留原始
datetime很关键） - ❌ 不必用：页脚“© 2024”，因为不指代具体事件时间点
- ❌ 不必用：倒计时数字（如
<span id="countdown">02:15:33</span>），它动态变化，不是静态语义时间
JavaScript 读取 time 元素时间时容易漏掉时区处理
用 el.dateTime 拿到的是字符串，不是 Date 对象。直接传给 new Date() 可能出错：
const t = document.querySelector('time');<br>console.log(new Date(t.dateTime)); // 若 datetime 无时区，会按本地时区解释
更稳妥的做法：
- 优先用
datetime值构造Date：它本身已是标准格式，new Date(t.getAttribute('datetime'))更明确 - 注意 Safari 对含微秒或不规范时区（如
+0800缺少冒号）兼容性差，建议统一用+08:00 - 如果后端返回的是 Unix 时间戳，别硬塞进
datetime——先转成 ISO 字符串再赋值
真正麻烦的不是怎么写，而是团队里有人随手删掉 datetime 属性还觉得“反正页面看着一样”。一旦开始做 RSS 输出、SEO 时间富媒体、或者接入日历订阅，这类缺失就立刻暴露。
