日期转时间戳

使用方法

1. 在「日期」选日子，范围 1970-01-01 ~ 2100-12-31（示例 2024-03-15）。选 1969 年会被拒绝，因为 Unix 时间戳从 1970-01-01T00:00:00Z 起算。
2. 在「时间」选时刻，范围 00:00:00 ~ 23:59:59，按秒递进（示例 08:30:45）。闰秒的 60 秒不设——Unix 时间戳按 POSIX 标准忽略闰秒。
3. 在「时区口径」选你输入的时刻属于哪个时区。选 UTC 时日期时间直接当 UTC 算；选 UTC+08:00 时会先减 28800 秒换算成 UTC。
4. 点「换算时间戳」。三个控件都是单行输入或下拉，直接按 Enter 就能算。
5. 结果区给出 8 格，其中「Unix 秒」是主结果。点「复制结果」带走四行文本，点「导出 CSV」拿 12 行日期对照表。

这个日期转时间戳能解决什么问题

一是接口联调时对不上数。后端要 timestamp、前端给 Date.now()、数据库存 datetime——三者混用时最容易出的错就是时区。典型症状是「同一条记录，页面显示的时间比数据库早 8 小时」，根源就是有人用了 new Date('2024-03-15')：这个写法按本地时区解析，而 Date.parse('2024-03-15T00:00:00Z')（带 Z）才是 UTC。

二是秒和毫秒搞混。Java 的 System.currentTimeMillis() 与 JS 的 Date.now() 给毫秒，PHP 的 time()、MySQL 的 UNIX_TIMESTAMP() 给秒。传错时接口会返回 1970 年附近的日期，或者干脆超出范围。13 位基本都是毫秒、10 位基本都是秒，本页对两种都做判定并把两个值同时给出。

三是算「某天 00:00 的时间戳」做按天分桶。日报、签到、账期这类逻辑都需要日界线。本页把日期固定解释为 UTC 后给你秒数（2024-03-15 是 1710460800），但要按中国时区分天，得用 1710432000（= 1710460800 − 28800）——两者差的就是那 8 小时。这一列对照表里每行都给了。

四是排查 2038 问题。用 32 位有符号整数存时间戳的系统（大量老旧嵌入式设备、部分数据库列）在 2038-01-19T03:14:07Z 之后会溢出回绕。本页在秒数超过 2147483647 时会把结果格标黄并写明回绕后的日期，让你提前发现这类隐患。

本页不做这些事：不做时间戳反查（那是时间戳转换工具的事）、不做时区、夏令时与夏令时切换的完整 tzdata 推算（本页面板只给四档固定偏移，不含历史时区变更）、不做闰秒补偿。要做完整时区换算请用时区转换器；要判断某年是否闰年请用闰年判断工具。

原理和变量

Unix 时间戳的定义是：从 UTC 1970-01-01T00:00:00Z 起经过的秒数，闰秒按 POSIX 标准被忽略。所以 new Date(0).toISOString() 必然等于 1970-01-01T00:00:00.000Z——这不是巧合，是定义。

关键在于怎么把「2024-03-15 08:30:45」变成一个毫秒数。JavaScript 有两条路，本页只走第一条：

• Date.UTC(y, m-1, d, H, M, S)：规范定义它直接返回 UTC 毫秒，完全不看本地时区。注意月份要减 1（Date.UTC 的月份是 0 起），这是最常见的低级错误。
• new Date(y, m-1, d).getTime()：这条是按本地时区解析的。实测在 UTC+08:00 机器上，Date.UTC(2024, 2, 15) 返回 1710460800000，而 new Date(2024, 2, 15).getTime() 返回 1710432000000，两者差 28800000 毫秒 = 8 小时。把系统时区改成 UTC，同一行代码就变成 1710460800000。

时区面板的四个档位对应固定偏移分钟数：0（UTC）、+480（UTC+08:00 = 28800 秒）、−300（UTC−05:00）、−420（UTC−07:00）。选非零档时，计算式是 Date.UTC(...) − 偏移分钟 × 60000——因为「UTC+08:00 的 08:30」对应的 UTC 时刻是 00:30。

输出为什么固定四格？因为往返一致性是检验口径是否自洽的硬判据：把 ISO 8601 串再解析回毫秒，必须得到完全相同的值。本页的「反解校验」输入框就是干这个的——Date.UTC 路线在 t −60 ~ 60 °C… 更正：在 1970 ~ 2100 年范围内的任意合法输入，往返偏差都是 0 毫秒（双精度浮点逐位相同）。而如果换成本地时区串，往返就会差 8 小时——这正是「为什么必须全程用 UTC 串」的直接证据。

秒与毫秒的判定规则是：13 位通常是毫秒、10 位通常是秒。经验分界是 1e9：1e9 秒 = 2001-09-09，而 1e9 毫秒 = 1970-01-12。但要注意单看数量级并不保险——实测 1e11 毫秒是 1973-03-03（合法），1e11 秒是 5138-11-16（也在 Date 范围内）。所以稳妥做法是「两种都算，看哪个落在 2001~2099 的业务窗口内」。

完整示例

默认这组：2024-03-15 08:30:45、时区 UTC（数值仅作演示）。

• 调用 Date.UTC(2024, 2, 15, 8, 30, 45)（月份 2 表示 3 月）
• 毫秒 = 1710491445000，秒 = 毫秒 ÷ 1000 = 1710491445
• ISO 8601 = 2024-03-15T08:30:45.000Z（toISOString() 永远输出 UTC 带 Z）
• 本地时区串（UTC+08:00 机器上）= 2024-03-15 16:30:45，与 UTC 差 8 小时
• 换成 UTC+08:00 口径时，08:30:45 对应的 UTC 是 00:30:45，秒数 = 1710491445 − 28800 = 1710462645
• 只取日期不取时间时（2024-03-15 00:00:00 UTC）：秒 = 1710460800；按 UTC+08:00 分天则是 1710432000，差 28800
• 2024-03-15 是星期五（2024 能被 4 整除且不能被 100 整除，是闰年，2 月 29 日存在）

换两组验证：1970-01-01 的秒是 0（纪元本身）；2038-01-19 的秒是 2147472000，仍未超 32 位上限（2040-01-01 才是 2208988800，已超）。下面表格里这四行可以逐位对照。

输入范围与对照表

三个控件的约束：日期 min="1970-01-01" max="2100-12-31" step="1"，时间 min="00:00:00" max="23:59:59" step="1"，时区四档固定偏移。日期格式由 <input type="date"> 保证为 YYYY-MM-DD，但 JS 侧仍会做一次回读校验——因为 Date.UTC 对不存在的日期会「顺延」而不是报错。

全部 12 行服务端直出，不依赖 JS 执行。默认示例那行标蓝，超 32 位上限的行标黄。

几个容易搞混的对照：

• 同一「2024-03-15」，UTC 口径是 1710460800，UTC+08:00 口径是 1710432000，差 28800。按天分桶时用哪个，取决于你的业务日界线定义在哪个时区。
• 1970-01-01 的 UTC+08:00 秒数是 −28800（负数）。这不是 bug——UTC+08:00 的 1970-01-01 00:00 比 UTC 纪元早 8 小时。
• 2038-01-19 秒 2147472000 未超上限，但同一天 03:14:07 之后就超了；上限值 2147483647 对应 2038-01-19T03:14:07Z。

边界与精度

1. Date 能表示的毫秒范围是 ±8,640,000,000,000,000（±8.64e15）。这等于 ±100,000,000 天，约 ±273,790 年。new Date(8.64e15) 还能用，new Date(8.64e15 + 1) 就是 Invalid Date，此时调 toISOString() 会抛 RangeError 让整页 JS 崩掉。所以本页在格式化前一律先判 Number.isFinite(d.getTime())。顺带说明：Number.MAX_SAFE_INTEGER 是 9007199254740991，但 new Date(9007199254740991) 本身就是 Invalid Date——安全整数上限并不在 Date 的有效范围内。

2. 闰秒不存在于时间戳里。POSIX 标准规定 Unix 时间戳忽略闰秒，所以 2016-12-31 23:59:60 UTC 不对应任何整数秒。历史上共发生过 27 次闰秒（1972-06-30 到 2016-12-31），累计 27 秒——这就是 NTP 与 Unix 系统之间的真实偏差量级。任何声称「精确到闱秒」的时间戳转换都不成立，因为时间戳本身没有这一位。

3. Date.UTC 对不存在的日期会顺延，必须回读校验。实测：Date.UTC(2024, 1, 30)（2 月 30 日）被顺延成 2024-03-01，Date.UTC(2023, 1, 29)（平年 2 月 29 日）顺延成 2023-03-01，Date.UTC(2024, 12, 1)（13 月）顺延成 2025-01-01，Date.UTC(2024, -1, 10)（0 月）顺延成 2023-12-10。不报错是最大的坑——所以判合法的正确做法是「Date.UTC 之后用 getUTCFullYear / getUTCMonth / getUTCDate 读回来比一遍」。

4. 闰年规则会影响 2 月 29 日。格里高利历规则是「能被 4 整除，且（不能被 100 整除，或能被 400 整除）」。实测：1900 平年、2000 闰年、2024 闰年、2023 平年、2100 平年、2400 闰年。所以 2100-02-29 是非法日期，2024-02-29 合法。日期输入框用浏览器原生控件时会自动屏蔽非法日期，但如果你要用代码批量生成，仍要自己判。

5. 2038 年上限的准确数值。2^31 − 1 = 2147483647 秒，对应 2038-01-19T03:14:07Z（UTC+08:00 机器上是 2038-01-19 11:14:07）。溢出一个单位即 2147483648 秒，32 位有符号会绕回 −2147483648，对应 1901-12-13T20:45:52Z——这就是「时间突然变成 1901 年」的成因。从 2026-01-01 算起还有 4401 天（约 12.05 年）。

6. 精度与显示位数。毫秒时间戳在 2^53 = 9007199254740992 之内都是精确整数，而有效毫秒上限是 8.64e15 < 2^53，所以整个 Date 有效范围内的毫秒值都是精确的，没有浮点误差。秒值是毫秒除 10000 得到的「整秒」时才恰好等于原始毫秒的 1/1000——本页只在秒本身不带毫秒余量时才输出，否则会在括号里注明。这是 Math.floor(ms / 1000) 与 Math.round(ms / 1000) 的区别所在。

常见问题

相关工具

• 时间戳转换工具：反方向，本页是「日期进时间戳出」，它是「时间戳进日期出」。
• 日期格式化转换器：需要把日期输出成 YYYY/MM/DD、DD-MM-YYYY 等其它格式时用。
• 时区转换器：需要跨时区对照、或处理夏令时与历史时区变更时用。
• 闰年判断工具：只判断闰年、且需要 400 年规则时用，页面上写了完整判定式。
• 日期加天数计算器：要「今天加 90 天」而不是「某天的秒数」时用。
• 工作日计算器：算日界线两侧的工作日归属，本页只给秒数不判断周末。
• 周数字计算器：需要 ISO 周数（getISOWeek() 口径，与本页面板的纪元口径不同）时用。