日志时间字段对齐
后端开发者在排查线上问题时，常从不同服务拉取日志。A 服务日志时间格式是 ISO 8601 的 2024-03-15T14:30:00Z，B 服务却是 RFC 2822 的 Fri, 15 Mar 2024 14:30:00 GMT。两个格式在同一个终端里混排，肉眼对比时间先后非常容易出错。用本工具把 RFC 2822 统一转成 ISO 8601，所有日志按同一时间轴排列，定位故障时间点从猜变成看。
粘贴任意日期字符串ISO 8601 / RFC 3339 / RFC 2822 / Unix 时间戳 / 中文日期
时间戳 ↔ 日期 双向转换 unix timestamp converter
就绪 · 粘贴或选择一个日期时间
第一节
关于本工具
About收到一个带时区偏移的RFC 2822字符串，比如'Thu, 01 Jan 2025 00:00:00 +0800'，要转成ISO 8601格式的'2025-01-01T00:00:00+08:00'，手动拆解容易错。这个工具在浏览器里直接解析三种标准——ISO 8601、RFC 3339、RFC 2822——并互相转换，支持时区偏移和Z后缀。所有解析和格式化都在本地执行，输入内容不会上传到服务器。
使用场景
API 响应时间校验
前端对接第三方支付接口时，文档要求请求头里的 Date 字段必须是 RFC 2822 格式，但本地测试环境生成的时间戳是 ISO 8601。手动拼字符串容易写错星期缩写或时区偏移，导致接口签名校验失败。把 ISO 8601 时间粘贴进本工具，一键转成 RFC 2822，再复制到请求头里，省去翻 RFC 文档查格式细节的功夫。
数据库迁移时区统一
DBA 把老系统（MySQL 的 datetime 字段存的是 RFC 3339 字符串）迁移到新库（要求全部转为 UTC 下的 ISO 8601）。老数据里混了 +08:00 和 +09:00 两种时区偏移，直接批量替换会弄乱时间。用本工具逐条校验每条记录的时区偏移是否正确，确认无误后再做批量转换，避免上线后用户看到错位订单时间。
邮件头时间解析
安全分析师收到一封可疑钓鱼邮件，需要从原始邮件头里的 Date 字段提取发件时间。邮件头用的是 RFC 2822 格式（如 Mon, 12 Aug 2024 09:15:22 +0800），但分析平台只接受 ISO 8601 格式的时间戳。手动换算时区容易算错，特别是跨夏令时边界时。用本工具把 RFC 2822 转成 ISO 8601，准确锁定发件时间，辅助判断该邮件是否在业务高峰期外发出。
配置文件中时间格式统一
运维在编排 docker-compose.yml 时，不同服务的环境变量对时间格式要求不一致。服务 A 的 TZ 变量要 ISO 8601 的 2024-03-15T14:30:00+08:00，服务 B 的 START_TIME 却要 RFC 3339 的 2024-03-15T06:30:00Z。手动改格式容易漏掉时区符号或把 Z 写成 +00:00 导致服务启动失败。用本工具把两个格式互转，确保每个服务的启动时间配置都符合其解析器预期。
对比矩阵
| 维度 | 本工具 | 竞品 A（在线转换站） | 传统方法（手动编写/正则） |
|---|---|---|---|
| 隐私 | 所有解析在浏览器内完成，不上传任何数据 | 需将日期字符串上传至对方服务器处理 | 完全本地，依赖用户自身环境 |
| 速度 | 即时解析，无网络延迟 | 受服务器响应和排队影响，通常 1-3 秒 | 取决于编码熟练度，数分钟至数小时 |
| 离线可用 | 纯前端实现，断网后仍可正常使用 | 必须联网，断网无法访问 | 完全离线，但需自行准备工具链 |
| 格式覆盖 | 支持 ISO 8601 / RFC 3339 / RFC 2822 及常见变体 | 通常只支持标准格式，变体易报错 | 需手动查阅 RFC 文档，易遗漏边界情况 |
| 易用性 | 粘贴即解析，无学习成本 | 需选择输入/输出格式，操作步骤多 | 需掌握正则表达式或编程语言日期库 |
| 批量处理 | 单次输入一条，适合快速验证 | 部分支持批量，但常限制条数或需付费 | 可写脚本批量处理，但调试成本高 |
第二节
使用指南
Getting Started使用步骤
- 1在输入框粘贴或键入 ISO 8601（如 2025-03-20T14:30:00Z）、RFC 3339 或 RFC 2822 格式的日期字符串，右侧结果区自动填充解析后的结构化时间组件
- 2点击「格式」下拉菜单，选择目标输出格式（ISO 8601 / RFC 3339 / RFC 2822），结果区同步更新转换后的字符串
- 3若输入时区偏移（如 +08:00 或 -05:00），结果区自动显示 UTC 时间与本地时间的对照行，无需手动换算
- 4点击结果区任意字段（年、月、日、时、分、秒）旁的复制图标，该字段值即写入剪贴板，页面顶部出现短暂提示
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| 2024-03-15T14:30:00Z | ISO 8601: 2024-03-15T14:30:00Z RFC 3339: 2024-03-15T14:30:00Z RFC 2822: Fri, 15 Mar 2024 14:30:00 +0000 | 常规：标准 UTC 时间戳，ISO 8601 与 RFC 3339 格式一致，验证基本互转能力 |
| 2024-12-31T23:59:59.999+08:00 | ISO 8601: 2024-12-31T23:59:59.999+08:00 RFC 3339: 2024-12-31T23:59:59.999+08:00 RFC 2822: Tue, 31 Dec 2024 23:59:59 +0800 | 常规：带毫秒和时区偏移的典型输入，验证毫秒精度和时区保留 |
| Thu, 01 Jan 1970 00:00:00 GMT | ISO 8601: 1970-01-01T00:00:00Z RFC 3339: 1970-01-01T00:00:00Z RFC 2822: Thu, 01 Jan 1970 00:00:00 GMT | 边界：Unix 时间戳零点，验证 RFC 2822 输入能否正确解析并输出其他格式 |
| 2024-02-29 | ISO 8601: 2024-02-29T00:00:00 RFC 3339: 2024-02-29T00:00:00 RFC 2822: Thu, 29 Feb 2024 00:00:00 +0000 | 边界：闰日（2024 闰年），验证日期解析对闰年支持正确 |
| 2023-02-29 | 错误：无效日期（2023 年不是闰年，2 月最多 28 天） | 易错：非闰年的 2 月 29 日，验证工具是否抛出明确错误而非静默回滚 |
| 2024-03-15T14:30:00.123456789Z | ISO 8601: 2024-03-15T14:30:00.123456789Z RFC 3339: 2024-03-15T14:30:00.123456789Z RFC 2822: Fri, 15 Mar 2024 14:30:00 +0000 | 边界：纳秒精度输入，验证工具是否支持超过 3 位小数（部分实现会截断或报错） |
| 2024-03-15 14:30:00 | ISO 8601: 2024-03-15T14:30:00 RFC 3339: 2024-03-15T14:30:00 RFC 2822: Fri, 15 Mar 2024 14:30:00 +0000 | 易错：空格分隔的日期时间（非标准 ISO），验证工具是否自动补 T 并正确解析 |
常见错误对照
1.ISO 8601 日期与时间之间缺少 'T' 分隔符
✗ 错误
2024-01-15 14:30:00✓ 修复
2024-01-15T14:30:00ISO 8601 严格规定日期与时间之间用大写字母 T 分隔，空格或其它字符均不符合规范，解析器会直接报错或返回 NaN。
2.时区偏移量格式错误，缺少冒号或符号
✗ 错误
2024-01-15T14:30:00 0800✓ 修复
2024-01-15T14:30:00+08:00RFC 3339 要求时区偏移量格式为 ±HH:MM，冒号不可省略；且正偏移必须写 + 号，负偏移写 - 号，不能仅写数字。
3.UTC 时间错误地附加了本地时区偏移
✗ 错误
2024-01-15T14:30:00Z+08:00✓ 修复
2024-01-15T14:30:00ZZ 后缀表示 UTC 时间，后面不能再跟任何偏移量。正确的 UTC 时间要么用 Z 结尾，要么用 +00:00，但二者不可同时出现。
4.RFC 2822 日期中月份名称拼写错误
✗ 错误
Mon, 15 Jan 2024 14:30:00 +0800✓ 修复
Mon, 15 Jan 2024 14:30:00 +0800RFC 2822 要求月份为英文缩写（Jan, Feb, Mar...），且首字母大写。拼写错误（如 Jann）或全写（January）均不符合规范，解析会失败。
5.日期与时间之间混入多余字符或空格
✗ 错误
2024-01-15T14:30:00.000+08:00 (UTC)✓ 修复
2024-01-15T14:30:00.000+08:00ISO 8601 / RFC 3339 不允许在日期时间字符串末尾附加注释或额外字符。解析器遇到非标准字符会截断或报错。
6.日期超出有效范围（如 2 月 30 日）
✗ 错误
2024-02-30T12:00:00Z✓ 修复
2024-02-29T12:00:00Z即使格式完全正确，日期值也必须符合公历规则。2024 年是闰年，2 月最多 29 天，30 日不存在，解析器会返回 Invalid Date。
7.时间部分的小时超出 24 小时制范围
✗ 错误
2024-01-15T25:00:00Z✓ 修复
2024-01-16T01:00:00ZISO 8601 时间采用 24 小时制，小时范围 00-23。25 小时不符合规范，应改为次日的 01:00，并相应调整日期。
8.RFC 2822 中星期名称与实际日期不匹配
✗ 错误
Tue, 15 Jan 2024 14:30:00 +0800✓ 修复
Mon, 15 Jan 2024 14:30:00 +08002024-01-15 是星期一，写成 Tue 会导致解析器忽略星期字段（部分实现）或直接报错。星期名称必须与实际日期对应。
第三节
工作原理
How It Works核心公式
Unix 时间戳 = (ISO 日期时间 - 1970-01-01T00:00:00Z) 的总秒数
变量说明
ISO 日期时间ISO 8601 格式字符串，如 2025-03-15T14:30:00ZUnix 时间戳自 1970-01-01 00:00:00 UTC 起的秒数
示例
输入 ISO 日期 2025-03-15T14:30:00Z，计算 Unix 时间戳：先计算天数差 = (2025-03-15) - (1970-01-01) = 20160 天（含闰年调整），再转为秒 = 20160 × 86400 = 1741824000，加上当日时间 14:30:00 对应的秒数 52200，得总秒数 1741876200。输出 Unix 时间戳 1741876200。
用户输入
本地处理
输出结果
第四节
开发者集成
For Developers6 种主流语言实现，复制即用：
from datetime import datetime, timezone
# ISO 8601 → RFC 2822
dt = datetime.fromisoformat('2025-03-15T14:30:00+00:00')
print(dt.strftime('%a, %d %b %Y %H:%M:%S %z')) # Sat, 15 Mar 2025 14:30:00 +0000
# RFC 2822 → ISO 8601
from email.utils import parsedate_to_datetime
dt2 = parsedate_to_datetime('Sat, 15 Mar 2025 14:30:00 +0000')
print(dt2.isoformat()) # 2025-03-15T14:30:00+00:00// ISO 8601 → RFC 2822
const dt = new Date('2025-03-15T14:30:00Z');
console.log(dt.toUTCString()); // Sat, 15 Mar 2025 14:30:00 GMT
// RFC 2822 → ISO 8601
const rfc = 'Sat, 15 Mar 2025 14:30:00 GMT';
console.log(new Date(rfc).toISOString()); // 2025-03-15T14:30:00.000Zpackage main
import (
"fmt"
"time"
)
func main() {
// ISO 8601 → RFC 2822
t, _ := time.Parse(time.RFC3339, "2025-03-15T14:30:00Z")
fmt.Println(t.Format(time.RFC1123Z)) // Sat, 15 Mar 2025 14:30:00 +0000
// RFC 2822 → ISO 8601
t2, _ := time.Parse(time.RFC1123Z, "Sat, 15 Mar 2025 14:30:00 +0000")
fmt.Println(t2.Format(time.RFC3339)) // 2025-03-15T14:30:00Z
}# ISO 8601 → RFC 2822（macOS / Linux）
date -j -f "%Y-%m-%dT%H:%M:%SZ" "2025-03-15T14:30:00Z" "+%a, %d %b %Y %H:%M:%S %z" 2>/dev/null || \
date -d "2025-03-15T14:30:00Z" "+%a, %d %b %Y %H:%M:%S %z"
# 输出: Sat, 15 Mar 2025 14:30:00 +0000
# RFC 2822 → ISO 8601（依赖 GNU date）
date -d "Sat, 15 Mar 2025 14:30:00 +0000" --iso-8601=seconds
# 输出: 2025-03-15T14:30:00+00:00import java.time.OffsetDateTime;
import java.time.format.DateTimeFormatter;
public class DateConvert {
public static void main(String[] args) {
// ISO 8601 → RFC 2822
OffsetDateTime dt = OffsetDateTime.parse("2025-03-15T14:30:00+00:00");
System.out.println(dt.format(DateTimeFormatter.RFC_1123_DATE_TIME));
// Sat, 15 Mar 2025 14:30:00 +0000
// RFC 2822 → ISO 8601
OffsetDateTime dt2 = OffsetDateTime.parse(
"Sat, 15 Mar 2025 14:30:00 +0000",
DateTimeFormatter.RFC_1123_DATE_TIME
);
System.out.println(dt2.toString()); // 2025-03-15T14:30:00Z
}
}<?php
// ISO 8601 → RFC 2822
$dt = new DateTime('2025-03-15T14:30:00+00:00');
echo $dt->format(DateTimeInterface::RFC2822) . "\n"; // Sat, 15 Mar 2025 14:30:00 +0000
// RFC 2822 → ISO 8601
$dt2 = new DateTime('Sat, 15 Mar 2025 14:30:00 +0000');
echo $dt2->format('c') . "\n"; // 2025-03-15T14:30:00+00:00
?>第五节
常见问题
Q & A问我复制了一段“2025-03-21T10:30:00.123+08:00”进去，工具说格式不对，哪里错了？＋
答
工具目前只接受标准 ISO 8601 / RFC 3339 / RFC 2822 格式，且不含毫秒部分。你贴的字符串里“.123”是毫秒，本工具暂不支持。去掉毫秒段，即输入“2025-03-21T10:30:00+08:00”就能正常解析。如果确实需要处理毫秒，建议先用记事本删掉小数部分再粘贴。
问为什么同一个时间戳转成 RFC 2822 和 ISO 8601 结果不一样？＋
答
两种格式的时区表示方式不同，但代表的是同一个时刻。RFC 2822 用“+0800”或“-0500”这种四位数字表示时区偏移，ISO 8601 则用“+08:00”带冒号。另外 RFC 2822 的日期部分会带星期缩写（如“Fri, 21 Mar 2025”），而 ISO 8601 是纯数字顺序。工具输出区会同时给出两种格式，你可以直接对比看，数值上的偏移量是一样的。
问输入“2025-03-21”这种只有日期的格式，工具能转吗？＋
答
可以。ISO 8601 允许只传日期不带时间，本工具会把日期解析为当天的 00:00:00（本地时区）再输出到其他格式。但注意，如果只传日期，工具默认使用你电脑的系统时区，不会自动补 UTC。如果你需要 UTC 的零点，建议手动在日期后加“T00:00:00Z”再输入。
问工具说“格式错误”，但我明明是从数据库直接复制出来的，怎么确认是不是我复制错了？＋
答
先检查字符串里有没有不可见字符，比如换行符、空格或 BOM 头。数据库导出时常见尾部多一个换行。建议粘贴后手动在末尾按退格键删一下，再试。另外有些数据库（如 MySQL）的 datetime 字段存的是“2025-03-21 10:30:00”不带 T，这种不是标准 ISO 8601，工具暂不支持。你需要在前面加个 T 变成“2025-03-21T10:30:00”才能解析。
问这个工具是纯前端处理的，我的日期数据会不会上传到服务器？＋
答
不会。本工具完全在浏览器本地运行，所有解析、转换代码都在你的电脑上执行。输入框里的日期字符串不会被发送到任何服务器，刷新页面或关闭标签后数据也不会留存。可以放心粘贴包含敏感信息（如内部系统日志、订单时间）的日期字符串。
问RFC 3339 和 ISO 8601 到底有什么区别？我该用哪个？＋
答
RFC 3339 是 ISO 8601 的一个子集，主要区别在于：ISO 8601 允许更多灵活性（比如省略年份、只写月份、带周数），而 RFC 3339 只允许完整的日期时间加时区偏移，且强制使用 T 分隔符。如果你是在写 API 或编程接口，推荐用 RFC 3339（更严格，兼容性更好）。如果你只是做通用日期记录，ISO 8601 更宽松。本工具同时支持两种作为输入，输出也会分别展示。
问为什么我输入“2025-03-21T10:30:00Z”转成 RFC 2822 后时区显示的是 +0000？＋
答
因为“Z”就是 UTC 的缩写，相当于 +00:00。RFC 2822 没有“Z”这种表示法，所以工具自动把它转成“+0000”。如果你希望输出显示某个特定时区（比如东八区），需要在输入时把 Z 改成对应的偏移量，例如“2025-03-21T18:30:00+08:00”。工具不会自动帮你转换时区，它只做格式转换，不改变实际时刻。
问这个工具能批量转换多个日期吗？我有一堆日志时间要处理。＋
答
不能批量。本工具每次只接受一个日期字符串，输出对应的三种格式。如果需要批量处理，建议用 Excel 公式或写脚本（如 Python 的 dateutil.parser）。本工具适合临时查一个日期、调试 API 返回的时间格式、或者验证某个字符串是否符合标准格式。如果你需要频繁批量转换，可以反馈需求，未来版本可能会增加批量粘贴功能。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。