Unix时间戳：全面解析及实用指南
日志里一列 1735689600，数据库导出里 created_at: 1735689600000，Excel 打开 CSV 日期变成 # 号------很多人不是不会编程，是没把「时间戳」这套语言翻译成人话。这篇把 Unix 时间戳是什么、哪儿会碰到、怎么少踩坑说清楚；需要随手换算时，文末有工具页地址。
时间戳到底是什么
Unix 时间戳 （常被简称为时间戳）表示：从 1970-01-01 00:00:00 UTC （Unix Epoch）起，经过了多少时间。习惯上存成整数，省空间、好排序、跨语言好传。
常见两种写法：
- 10 位 ：一般是秒 （例如
1735689600）。 - 13 位 ：一般是毫秒 （例如
1735689600000），JavaScript、很多前端和 Java 生态里常见。
把毫秒当秒，日期会飞到离谱的未来或过去；把秒当毫秒，又几乎全挤在 1970 年附近。排查接口、对日志，先看位数比啥都管用。
时间戳本身不带时区------它标记的是同一绝对时刻。你看到的「本地时间」「北京时间」，是展示层按时区翻译出来的；UTC 字符串、ISO 8601 则是另一种人类可读格式，写文档、对国外同事时常用。
时间戳在线转换 https://gegegj.com/calc/timestamp
时间戳用来干什么
程序里存时间 ：数据库字段、JSON 接口、埋点事件，用数字比存 "2025-01-01 12:00:00" 更统一，也不容易被各语言日期解析坑。
排序与区间查询：按数字比大小就是比先后，索引友好。
日志与监控：ELK、Prometheus、云厂商控制台，底层经常是秒或毫秒；排障时要把它还原成「几点几分」。
跨系统协作：A 系统吐 Unix 秒，B 系统要 ISO 8601，中间就需要转换层------不一定写代码，临时查一下也行。
它不是 墙上挂钟的「北京时间几点」，而是时间轴上的一个刻度；同一刻度，在上海、伦敦、纽约读出来的本地钟点不同，但刻度本身一样。
哪些情况你会用到
- 读后端/数据库导出 ：
updated_at、event_time是一串数字。 - 联调接口：文档写「Unix 毫秒」，你 Postman 里填的是秒。
- 对日志 ：报错说某请求在
1710000000发生，要和对端、对 DB 对齐。 - Excel / CSV：日期列被当成数字或科学计数，怀疑其实是时间戳。
- 写测试数据：要造「明天此时」的时间戳，手算容易错。
和「我在纽约开会几点」不是一类问题------那是同一时刻在不同城市的钟点 ，更适合 https://gegegj.com/calc/timezone 这种多时区对照；时间戳页解决的是数字 ↔ 日期时间。
在线转换适合干什么（以及不干什么）
https://gegegj.com/calc/timestamp 这类页面，典型用法是：
时间戳 → 可读时间：粘贴纯数字（自动区分 10 位秒 / 13 位毫秒），看本地时间、UTC 字符串、ISO 8601；可点「填入当前时间戳（秒）」抓现在的刻度。
日期时间 → 时间戳 ：选本地 YYYY-MM-DDTHH:mm，反查对应 Unix 秒和毫秒，写用例、填文档方便。
计算在浏览器本地 完成，适合临时核对；不提供时间戳加减 （「七天后是多少」要另算或写脚本）。不同语言、数据库、ORM 对时区、字符串解析的规则可能略有差异，生产对账以源系统文档为准。
容易混的几件事
UTC 和本地 ：时间戳转出来会同时给 UTC 与本地，写工单建议两个都贴，减少「差八小时」的锅。
ISO 8601 里的 Z 和 +08:00：表示的是带时区偏移的字符串，和时间戳是不同层级的表示，别混在一个字段里改来改去。
闰秒：极少数系统历史上对闰秒处理不一致，一般业务碰不到；碰到了以平台公告为准。
Excel 日期序列值：有时单元格显示的是 1900 起算的天数，不是 Unix 戳，别见数字就按 Epoch 硬套。
总结
Unix 时间戳就是从 1970-01-01 UTC 起算的整数刻度 ，10 位多为秒、13 位多为毫秒；它方便程序存储排序，人眼不友好，所以要有「转日期」这一步。日常排错记住：先看位数，再对 UTC/本地，留原始数字。跨城会议钟点则交给时区页。别把在线结果当法律文书或审计最终依据，关键系统以官方日志与数据库配置为准。
#Unix时间戳# #时间戳转日期# #13位毫秒戳# #UTC时间# #ISO8601# #在线工具# #鸽鸽工具网#