什么是 Unix 时间戳？
Unix 时间戳（Unix Timestamp）是指从 1970 年 1 月 1 日 00:00:00 UTC 到指定时间点所经过的秒数或毫秒数。它是计算机系统中广泛使用的时间表示方式，具有时区无关、格式统一、便于计算和存储等优点。
秒级时间戳通常为 10 位数字（如 1712345678），毫秒级时间戳为 13 位数字（如 1712345678000）。本工具支持自动识别输入的精度，也可以手动指定。
如何使用时间戳转换工具？
时间戳转日期时间
- 在左侧输入框粘贴 Unix 时间戳（如 1712345678 或 1712345678000）
- 选择精度：自动识别 / 秒 / 毫秒
- 点击"转换"按钮，右侧显示对应的北京时间（精确到毫秒）
日期时间转时间戳
- 在右侧选择日期时间，或使用"获取当前日期"自动填入
- 点击"转换"按钮，右侧同时显示秒级和毫秒级时间戳
使用说明
- 自动识别：输入长度 ≤ 10 位视为秒，> 10 位视为毫秒
- 北京时间：所有日期时间输出均为东八区（UTC+8）北京时间
- 毫秒精度：支持显示和转换到毫秒级（YYYY-MM-DD HH:mm:ss.sss）
- 纯前端处理：数据仅在浏览器本地计算，不上传服务器
常见应用场景
- 前后端接口调试时，将 API 返回的时间戳转换为可读日期
- 数据库中存储的时间戳字段快速查看实际时间
- 生成特定日期对应的 Unix 时间戳用于代码测试
- 对比不同精度（秒/毫秒）的时间戳差异
常见问题
为什么我用 JavaScript 的 new Date(1712345678) 得到的是 1970 年？
因为 JavaScript 的 Date 构造函数默认按毫秒计算，直接传入 10 位秒级时间戳 1712345678，就相当于 1970 年 1 月 1 日 00:00:00 UTC 之后多了 1712345678 毫秒（约 19.8 天），所以落在 1970 年 1 月 20 日附近。正确写法是 new Date(1712345678 * 1000)，或先用 parseInt 判断位数再补单位。本工具内部已自动换算，粘贴任意位数的值即可得到正确结果。
为什么我用本工具把日期时间转成时间戳，和网上其他工具的结果差了 8 小时？
Unix 时间戳是 UTC 绝对时刻，同一瞬间在任何时区数值都相同，差异只可能来自"把日期解析成时刻"这一步的时区设置。本工具的日期输入框按东八区（Asia/Shanghai）解析；如果你的操作系统时区不是 UTC+8，而另一个工具按本地时区或 UTC 解析，同一串日期文字就会产生 ±8 小时偏差。跨时区协作时，先把两边的时区假设对齐再比较结果。
2038 年问题是什么？我的程序会受影响吗？
2038 年问题源于 32 位有符号整数存时间戳：最大能表示 2 的 31 次方减 1 秒，即 2147483647，对应 2038 年 1 月 19 日 03:14:07 UTC，再往后会溢出成负数。现代 64 位系统、主流编程语言和浏览器都不受影响；JavaScript 的 Number 是双精度浮点，处理秒和毫秒都远超这个范围。只有老旧的 32 位嵌入式设备、老版本 PHP 或某些数据库时间字段才需要排查。
为什么我粘贴的 10 位数字转出来是 2001 年，而不是我想的日期？
很可能你把"位数"和"单位"搞混了。1000000000（10 位）在秒级下是 2001 年 9 月 9 日，但如果它实际是毫秒值，对应的时刻只有 1970 年 1 月 1 日 00:16:40。反过来，13 位毫秒如 1712345678000 如果被当秒处理，会得到远超当前年份的日期。判断依据是数值量级而非直觉：当前时刻的秒级是 10 位、毫秒级是 13 位，明显不符的值通常是传错单位了，手动切换"秒/毫秒"再转换即可核对。
为什么我的 13 位时间戳粘贴到 Excel 后变成了科学计数法，末几位变成 0？
Excel 的数字精度只有 15 位有效数字，13 位毫秒时间戳往往超过这个范围，会被自动转成科学计数法并舍入，导致精度丢失、无法还原真实时间。这也是"时间戳精确到毫秒"的场景不建议直接存 Excel 的原因。处理办法：先把 Excel 单元格格式设为文本再粘贴，或在导出时人为加上前导字符（如加一个单引号）强制按文本保存。
