分析服务器日志错峰
凌晨 3 点 17 分 42 秒，服务器突然 CPU 飙升到 95%。运维从日志里翻出一串毫秒级时间戳 `1698844662123`，需要快速判断这个时间点对应的是哪个业务高峰。把毫秒戳丢进工具，直接转成北京时间 `2023-11-02 03:17:42.123`，并同步显示 UTC 时间。对比发现，这个时间点正好是北美用户批量同步数据的窗口开启时刻，之前一直以为是国内晚高峰导致的误判，现在证据确凿，直接调整了同步策略。
UNIX TIMESTAMP · NOW
——————————
—毫秒 / ms
载入中…
时间戳 → 日期Timestamp → Date
日期 → 时间戳Date → Timestamp
位数自动识别：10 位=秒 · 13 位=毫秒 · 16 位=微秒 · 19 位=纳秒，支持小数秒与负值
世界时钟 · 14 时区
following the live clock · 朱砂描边 = 你的本地时区
批量转换
每行一个 · 时间戳或日期文本可混填 · 结果可导出 CSV
第一节
关于本工具
About后端返回的时间戳是秒还是毫秒？调试接口时猜错单位，差出几十年。这个工具把秒、毫秒、微秒到年月日时分秒的转换并排展示，一眼就能确认单位，并支持同时比对多个时区的时间。所有计算在浏览器本地完成，时间戳和日期数据不会离开设备——更适合处理日志、API 响应等敏感时间数据时使用。
使用场景
核对跨国会议邀请
海外客户发来一封邮件，会议时间写的是 `1700000000`（秒级时间戳）。国内同事习惯看北京时间，而客户在洛杉矶。把时间戳输入工具，左侧输入框选「秒」，右侧结果区同时显示了北京 `2023-11-15 10:13:20` 和洛杉矶 `2023-11-14 18:13:20` 两个时区的时间。避免了因为时区换算错误而把会议定在凌晨的尴尬，也省去了手动加减 16 小时的麻烦。
验证程序埋点数据
前端工程师在 App 里埋了一个用户点击事件，上报的时间戳是微秒级 `1698844662123456`。后端同学收到数据后，发现这个数字超出了常规的秒级范围，无法直接入库。把微秒戳输入工具，工具自动识别为微秒，并转出精确到微秒的日期时间 `2023-11-02 03:17:42.123456`。前后端据此统一了时间精度单位，避免了因单位不匹配导致的数据入库异常。
对接金融交易流水
银行回传的交易流水文件里，时间字段是 Unix 毫秒时间戳 `1698844662123`。财务人员需要把这些时间戳和 Excel 里的日期格式做匹配，以便按日对账。把毫秒戳复制进工具，立即得到标准日期 `2023-11-02 03:17:42`。工具还支持批量转换，把整列时间戳一次性处理，生成可粘贴回 Excel 的日期列，整个过程不到 30 秒。
调试物联网设备离线
智能水表上报的离线时间戳是 `1698844662`（秒级），但设备固件里记录的时钟是 UTC 时间。需要判断这个离线时刻是北京时间几点，以便安排维修人员上门。把时间戳输入工具，选择「UTC」时区，工具显示 UTC 时间 `2023-11-01 19:17:42`，再切换时区到「北京时间」显示 `2023-11-02 03:17:42`。发现离线发生在凌晨，确认是设备电池耗尽，而非网络故障。
第二节
使用指南
Getting Started使用步骤
- 1在输入框粘贴或键入时间戳数值（如 1700000000），下方实时显示对应的 UTC 日期时间
- 2点击「时区」下拉菜单选择目标时区（如 Asia/Shanghai），日期时间自动重算并刷新
- 3切换「秒/毫秒/微秒」单位开关，输入值按新单位重新解析，结果同步更新
- 4点结果行右侧「复制」图标，将当前日期时间字符串复制到剪贴板
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| 1700000000（秒 → 日期） | 2023-11-14 22:13:20 (UTC+8) | 常规：Unix 时间戳的典型值，验证基本秒级转换，用户最常用场景 |
| 1700000000000（毫秒 → 日期） | 2023-11-14 22:13:20.000 (UTC+8) | 常规：JavaScript 等前端常用毫秒级时间戳，验证毫秒与秒的 1000 倍关系 |
| 0（秒 → 日期） | 1970-01-01 08:00:00 (UTC+8) | 边界：Unix 纪元零点，验证东八区偏移正确（UTC+8 显示 08:00:00 而非 00:00:00） |
| 2147483647（秒 → 日期） | 2038-01-19 11:14:07 (UTC+8) | 边界：32 位有符号整数最大值，2038 年问题临界点，验证工具是否支持 64 位时间戳 |
| 9999999999999（微秒 → 日期） | 2286-11-20 17:46:39.999999 (UTC+8) | 边界：微秒级超长时间戳，验证工具对 13 位以上输入的处理能力（是否溢出或截断） |
| 1700000000.5（秒 → 日期） | 2023-11-14 22:13:20.500 (UTC+8) | 易错：带小数点的秒级时间戳，验证工具是否支持浮点数输入并正确显示毫秒部分 |
| 2023-11-14 22:13:20（日期 → 秒） | 1700000000 | 易错：日期转时间戳的逆向操作，验证双向转换一致性，且需注意时区默认行为 |
常见错误对照
1.毫秒时间戳当作秒传给工具
✗ 错误
输入 1712345678000，期望得到 2024-04-05 12:34:38✓ 修复
输入 1712345678（秒级）或切换工具到毫秒模式再输入 1712345678000JavaScript 的 Date.now() 返回毫秒级时间戳（13 位），而 Unix 标准时间戳是秒级（10 位）。差 1000 倍，结果会偏移约 1970 年。
2.时区参数缺失导致时间偏差
✗ 错误
输入 1712345678，工具输出 2024-04-05 12:34:38，但用户实际在东八区，期望 20:34:38✓ 修复
在时区下拉选择 UTC+8（Asia/Shanghai）后再查看结果工具默认可能使用 UTC 或浏览器本地时区。不指定时区时，同一时间戳在不同时区下显示的小时数不同，跨时区协作必须显式指定。
3.微秒时间戳直接当秒输入
✗ 错误
输入 1712345678123456，工具报错或返回异常日期✓ 修复
先确认时间戳单位：微秒是 16 位数字，需在工具中选择“微秒”模式再输入微秒级时间戳（16 位）超出秒级（10 位）的数值范围，直接输入会导致溢出或截断。工具按单位解析，单位选错结果全错。
4.日期转时间戳时忽略 UTC 与本地时区差异
✗ 错误
输入日期 2024-04-05 12:34:38，期望得到 1712345678（实际 UTC 时间戳）✓ 修复
输入日期时明确时区（如 2024-04-05 12:34:38 UTC+8），或使用工具提供的“当前时区”选项日期转时间戳的基准是 UTC 1970-01-01 00:00:00。如果输入的日期不带时区，工具可能按 UTC 解析，导致与本地时间差 8 小时。
5.负时间戳（1970 年之前）被当作无效输入
✗ 错误
输入 -123456789，工具提示“请输入正整数”或返回空✓ 修复
确认工具支持负时间戳后，输入 -123456789 并选择秒模式Unix 时间戳允许负值表示 1970-01-01 之前的日期。部分工具默认只校验正数，需查看工具说明是否支持负时间戳。
6.带小数的时间戳未处理精度
✗ 错误
输入 1712345678.123，工具只显示整数秒，丢失毫秒部分✓ 修复
将小数部分作为毫秒/微秒处理：输入 1712345678123（毫秒）或使用支持小数秒的工具时间戳规范中秒级可带小数表示亚秒精度。但多数转换工具只接受整数，小数部分会被截断，导致精度丢失。
7.误将十六进制或字符串时间戳直接输入
✗ 错误
输入 0x66123456 或 "2024-04-05"，工具报错或返回 0✓ 修复
先将十六进制转为十进制（0x66123456 = 1712345670），或确认工具是否支持自动识别格式时间戳必须是十进制整数。十六进制、带引号的字符串、日期格式字符串都不是有效时间戳，工具不会自动转换。
第三节
工作原理
How It Works核心公式
Unix 时间戳 = (目标日期 - 1970-01-01 00:00:00 UTC) 的总秒数
变量说明
目标日期待转换的日期时间，含时区信息1970-01-01 00:00:00 UTCUnix 纪元起点，UTC 时区总秒数两个时刻之间的秒数差，整数
示例
将北京时间 2024-03-15 10:30:00 转为 Unix 时间戳。先转为 UTC：2024-03-15 02:30:00 UTC。计算与 1970-01-01 00:00:00 UTC 的秒差：天数差 = 19800 天（含闰年），秒数 = 19800 × 86400 = 1,710,720,000，再加 UTC 当天 2 时 30 分 = 2×3600 + 30×60 = 9,000 秒。最终时间戳 = 1,710,720,000 + 9,000 = 1,710,729,000。
用户输入
本地处理
时区换算
输出结果
第五节
常见问题
Q & A问我有个带毫秒的时间戳，比如 1700000000123，怎么转成日期？＋
答
直接输入到本工具的输入框即可。工具会自动识别数字长度：10 位是秒、13 位是毫秒、16 位是微秒。1700000000123 是 13 位，工具会当作毫秒处理，转出对应的年月日时分秒。如果不确定位数，可以看输入框下方的提示，它会在你输入时实时显示当前识别到的单位。
问为什么同一个时间戳，在不同网站上转出来的日期不一样？＋
答
大概率是时区设置不同。Unix 时间戳是 UTC 绝对时间，但不同工具默认显示时区可能不一样——有的固定显示 UTC，有的按浏览器本地时区。本工具在结果区同时显示 UTC 和本地（东八区）两行，并标注当前时区偏移，方便直接对照，不用自己换算。
问我输入 10 位数字，工具怎么没反应？＋
答
检查一下输入是否包含空格、逗号或引号。工具只识别纯数字，且不接受负数时间戳（1970 年之前的日期）。如果输入 10 位数字后结果区空白，可以刷新页面再试一次。另外，本工具完全在浏览器运行，不依赖网络，如果页面卡住通常是浏览器内存问题，关掉其他标签页即可。
问这个工具能转负数时间戳吗？比如 -86400 这种？＋
答
目前不支持。负数时间戳代表 1970-01-01 之前的日期，本工具输入框只接受 0 及以上的正整数。如果需要转换 1970 年以前的日期，建议用专门的日期计算工具或手动推算。本工具主要覆盖 1970 年之后的常见时间戳场景。
问我有一堆时间戳，想批量转成日期，能一次粘贴很多行吗？＋
答
本工具是单次转换设计，输入框只接受一个时间戳。如果需要批量处理，可以手动逐条粘贴转换。如果操作频繁，建议用 Excel 公式或写脚本批量处理——本工具定位是快速查单个时间戳，不做批量处理。
问工具显示的时间是 UTC 还是北京时间？我该怎么看？＋
答
结果区同时显示两行：一行标注「UTC（+00:00）」是协调世界时，一行标注「本地（+08:00）」是东八区北京时间。如果服务器或日志里存的是 UTC 时间，直接看第一行；如果日常使用，看本地行即可。两行之间差了正好 8 小时，是正常的。
问这个工具需要联网吗？没网能不能用？＋
答
完全不需要联网。本工具是纯前端实现，所有计算在浏览器内完成，不会把你的时间戳发送到任何服务器。断网状态下照样可以打开页面使用，适合本地开发环境、内网服务器或网络受限的场景。隐私方面也可以放心，输入的数据不会离开你的电脑。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。