JavaScript 的 Date.now() 粘贴进时间戳工具，为什么要除以 1000？

Unix 时间戳从 1970-01-01 00:00:00 UTC 起算的秒数，常见是 10 位，例如 1710000000。JavaScript `Date.now()`、`new Date().getTime()` 返回的是毫秒，13 位，例如 1710000000000。把 13 位数当秒填进只认 10 位的换算框，会得到荒谬日期；把 10 位数当毫秒，会显示 1970 年附近。

在 Unix 时间戳换算 粘贴时先看位数：13 位一般选毫秒，10 位选秒。接口文档写 `created_at` 是 int 还是 long、单位是 s 还是 ms，比背公式重要，见 秒还是毫秒。

Excel 序列号不是 Unix，见 Excel 序列号。日志差 8 小时先看时区，见 日志时区。数据库 0 与空值见 null 与 0。

和后端约定字段名 + 单位 + 时区（UTC 还是 +8）。前端展示用 `new Date(ms)`，传 API 时若对方要秒则 `Math.floor(Date.now()/1000)`。不要用字符串拼接时区偏移到时间戳上。

让后端在文档里写清：字段名、单位秒还是毫秒、时区是 UTC 还是东八区存储、是否字符串类型。前端 `parseInt` 截断大数会溢出，超过 `Number.MAX_SAFE_INTEGER` 的毫秒时间戳要用 BigInt 或字符串处理。

日志里若同时有 `time` 和 `time_ms` 两列，先确认复制的是哪一列，见秒毫秒合同文。

把换算结果和运维系统、数据库客户端显示的时间三点对齐，差八小时先查时区再查位数。

历史数据迁移时，有人把秒误乘一千写入库，查询会出现公元三千年后的日期，抽样几条用工具反查可批量发现。

Excel 导出列若显示科学计数法，复制前先把列格式设为文本，避免末位被吃掉。

用户界面显示「多久以前」可用相对时间库，底层存储仍建议 UTC 毫秒。展示层再转本地时区。

不要把格式化后的日期字符串 `2026-05-21 12:00:00` 再当时间戳传回去，除非明确约定格式和时区。

Safari 对 `YYYY-MM-DD` 解析有时按 UTC 午夜，和 Chrome 不一致，接口层用数字时间戳更稳。

单元测试里固定 `Date.now` mock 时，记得测试里也用同一单位，避免测试通过线上炸。

本文围绕「Unix 时间戳换算」的一个常见问题展开，工具在浏览器本地计算，适合试算与沟通；正式办事仍以银行、税务、医院、合同文本为准。

涉及隐私的数据请先脱敏；公共电脑、录屏环境勿粘贴真实工资、病历、Token 或合同金额。

打开 Unix 时间戳换算，先用文中例子或虚构小数据点一次按钮，确认输出长什么样，再换成你的真实数字。第一次只求跑通，不必纠结差一两元、差一天。

把输入项逐栏核对：单位是否选错、日期是否按「年-月-日」、利率是「年利率」还是「月利率」、金额有没有多写零。九成「算不对」其实是口径不一致，不是公式神秘。

若页面有「复制结果」或表格输出，可粘贴到备忘录与官方材料并排；截图时尽量带上输入区，方便过几天回看自己当时用的参数。

计算在浏览器本地完成，适合个人快速试算；涉及合同、税务申报、医疗、放贷等，请保留书面凭证并咨询对应机构。公共电脑、录屏直播环境请勿粘贴未脱敏的证件号、卡号、Token、完整病历。

`Date.now()` 是毫秒；换算前对位数，用 时间戳工具 选对秒/毫秒。合同与日志以系统文档为准。