UNIX TIME / 1970 — NOW 本地换算 · 无需登录 · 秒与毫秒都支持

时间戳转换器把每一秒，读成你熟悉的时间

输入一串 Unix 时间戳，立即看到它在北京时间、UTC 或本地时区里的日期；也可以反过来，把某个钟表时间写成秒级与毫秒级时间戳。10 位、13 位、16 位、19 位会自动辨认，ISO 8601、星期与年内天数一并给出。

ONLINE CONVERTER

时间戳转换

按 1、2、3 步填写，结果会自动更新，也可以点击转换按钮确认。

当前时间戳
秒级

毫秒级 — · 北京时间 —

批量转换

支持 10 位秒级、13 位毫秒级、16 位微秒和 19 位纳秒，系统会自动识别。

快速填入

选择输入单位和显示时区

切换显示时区只改变显示方式，不改变时间戳代表的绝对时间点。

输入内容后结果会自动更新；点击按钮可以立即确认当前输入。

转换结果会显示在这里在上方输入时间戳，或点击“填入当前时间”先试试看。
全部换算在浏览器本地完成，输入不会上传到服务器 时区规则来自浏览器内置的 IANA 数据库
不上传输入内容 不保存转换记录 页面打开即可使用
01 / LOCAL

浏览器里算完

输入只停留在当前页面，刷新即消失，不经过我们的服务器。

02 / UNIT

单位自动辨认

按数量级识别秒、毫秒、微秒和纳秒，也可以手动锁定。

03 / ZONE

时区写得明白

同一个时间点，分别用北京、UTC、本地或海外城市呈现。

04 / FREE

不设使用门槛

不注册、不订阅、不限制次数，手机与桌面浏览器都能用。

THE COORDINATE OF TIME

时间戳不是随机数字，
而是通往 UTC 的坐标

Unix 时间戳记录的是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数。它不携带“北京时间”或“纽约时间”这类标签，只描述一个绝对的时间点。也正因为它足够中性，服务器、数据库和不同国家的程序才能用同一个数字对话。

当你把它转换成日期，真正发生的事情是：先确定这个数字代表哪一刻，再选择用哪条经线上的钟表来显示。时间戳本身没有变，变的只是观察它的角度。本站把这两步拆开显示，就是为了让你看清“时间点”和“时区显示”之间的区别。

一个容易记的对照1767225600 表示 2026-01-01 00:00:00 UTC；在北京时间下显示为 2026-01-01 08:00:00。数字相同，钟表时间相差 8 小时。

WHAT IT DOES / 功能

从“看懂”到“用上”，
中间不多绕一步

常用转换工具只给一个日期结果，真正工作时却常常还需要 ISO 格式、毫秒值、星期、时区偏移和可复制的文本。这里把这些结果放在同一张工作台上，减少来回切换。

01 / CONVERT

双向换算

时间戳转日期，日期转时间戳。切换方向不会丢掉已经输入的内容，结果即时更新。

打开完整工作台
02 / DETECT

四位单位

除了常见的 10 位秒和 13 位毫秒，也能处理 16 位微秒与 19 位纳秒，避免数量级误判。

了解单位规则
03 / ZONE

时区并排看

北京时间、UTC、本地时间与十个海外城市，按真实 IANA 规则换算，夏令时也考虑在内。

进入时区换算
04 / COPY

结果可直接用

秒、毫秒、ISO 8601、UTC、时区偏移都能单独复制，也可以一键复制整段排查记录。

批量处理数据

WHERE IT HELPS / 场景

三种最常见的使用现场

时间戳出现在接口、日志、数据库和排期表里。下面这些场景不需要额外安装软件，打开页面就能完成核对。

SCENE 01

接口联调

接口返回 1767225600，先确认它是秒还是毫秒，再分别看 UTC 与北京时间，最后把 ISO 字符串贴进日志或测试用例。遇到奇怪的时间差，可以顺着本站的排查清单逐项核对。

查看接口时间检查清单
SCENE 02

日志与数据清理

从日志里复制一列时间戳，批量转成可读日期，导出 CSV 再交给表格处理。自动识别单位能减少“1970 年”或“5000 年”这类明显错误，也能保留原始行号方便回查。

批量转换一列时间戳
SCENE 03

跨城协作

北京团队下午三点开会，纽约同事看到的是几点？把日期和源时区填进去，目标城市的日期、时间与 UTC 偏移会一起显示，跨日的情况也会标出来。

换算会议时间

SECONDS OR MILLISECONDS

秒，还是毫秒？
先看数量级，再看字段

最直观的判断是数位数：当前时间点的秒级时间戳通常是 10 位，毫秒级是 13 位。但只数位数并不永远安全，因为更早或更远的日期会改变位数，负数时间戳也会让长度判断变得别扭。

更稳妥的做法是结合数量级和字段含义一起看：如果一个数换算后落在 1970 年附近，往往是把毫秒当成了秒；如果落在几万年以后，则可能是把秒当成了毫秒。本站的自动识别以数量级为主，同时允许你手动指定单位，避免“看起来对了”的误判。

判断口诀13 位多为毫秒，10 位多为秒；16 位看微秒，19 位看纳秒。真正入库前，再用一个已知时间点反向验证一次。
位数单位示例常见来源
10 位秒1767225600后端接口、Redis、Unix 命令
13 位毫秒1767225600000JavaScript、日志、移动端
16 位微秒1767225600000000高精度数据库、部分 SDK
19 位纳秒1767225600000000000系统调用、性能计时

示例都以 2026-01-01 08:00:00（北京时间）为同一个时间点。超过 13 位的值在 JavaScript 中可能损失精度，处理时优先用字符串或 BigInt。

QUICK REFERENCE / 速查

此刻附近的时间戳

打开页面时按当前时间生成，方便快速对照。需要精确到某一秒时，直接用上方的转换器或批量工具。

时间点秒级时间戳毫秒级时间戳北京时间
此刻页面加载后自动计算

速查表跟随你的设备时间生成，仅作为日常对照。生产环境请以服务端时间为准。

BACK TO CODE / 代码

把刚才的结果，
带回代码里

不同语言对“秒”和“毫秒”的默认约定并不一致。下面只保留最常用的一行，完整的语言示例、数据库写法和排查顺序放在使用指南里。

JAVASCRIPT / 浏览器与 Node
const now = Math.floor(Date.now() / 1000); // 秒
const ms = Date.now();                      // 毫秒

const shanghai = new Intl.DateTimeFormat('zh-CN', {
  timeZone: 'Asia/Shanghai',
  dateStyle: 'medium',
  timeStyle: 'medium',
  hourCycle: 'h23'
}).format(new Date(ms));
PYTHON 3.9+
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

now = datetime.now(timezone.utc)
seconds = int(now.timestamp())
beijing = now.astimezone(ZoneInfo("Asia/Shanghai"))

print(seconds, beijing.isoformat())

再补一行 SQL，方便在数据库里核对：SELECT UNIX_TIMESTAMP(NOW()) 得到秒级时间戳，FROM_UNIXTIME(1767225600) 则把它转回数据库会话时区下的日期时间。注意，MySQL 的 FROM_UNIXTIME 受会话时区影响，和前端看到的北京时间未必相同。

阅读完整使用指南：原理、单位、时区、2038 与各语言示例 →

BEFORE YOU ASK / 先看这里

四个高频问题

如果下面的回答还没有解决你的疑问，常见问题页按“基础概念、转换结果、使用与隐私”分了组，可以继续查。

10 位和 13 位时间戳有什么区别？

10 位通常是秒级，13 位通常是毫秒级，两者正好相差 1000 倍。比如 1767225600 与 1767225600000 指向同一时刻。真正转换前，最好确认接口字段的单位，而不是只看页面显示。

转换后为什么和接口里的时间差 8 小时？

时间戳本身是 UTC 坐标，不包含时区。差 8 小时通常是因为一方把北京时间当成了 UTC，或者把 UTC 直接当成了北京时间展示。先确认“数字有没有变”，再确认“显示时区选的是哪一个”。

时间戳会过期吗？2038 年是怎么回事？

标准的 64 位时间戳可以用很久，日常生活里不用担心过期。2038 年问题来自部分系统使用 32 位有符号整数存储秒级时间戳，上限是 2147483647，对应 2038-01-19 03:14:07 UTC。新系统通常已经改为 64 位。

输入的数字会被上传或保存吗？

不会。转换逻辑在浏览器里执行，输入与结果不会发送到服务器，也不写入本地存储。页面只加载百度统计脚本了解访问情况，统计脚本不读取输入框、结果区或剪贴板。

查看全部时间戳常见问题 →

ONE MORE CHECK

换一个时间，再核对一次

时间数据最怕“看起来对”。把接口返回值、数据库记录和页面展示放在同一套时区里，再走一遍转换，往往比盯着代码猜更快。

打开转换工作台 读使用指南