FAQ / UNIX TIME
时间戳常见问题
把时间戳转换中最容易混淆的问题集中在这里：位数与单位、8 小时误差、闰秒与夏令时、2038 年边界，以及输入数据会不会被上传。每个回答都尽量给出可执行的判断方法，而不只是结论。
基础概念
什么是 Unix 时间戳？为什么从 1970 年开始？
Unix 时间戳表示从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数。这个起点是早期 Unix 系统采用的时间基准，后来成为跨系统表示时间点的通用方式。它只是一个约定，不代表时间本身从 1970 年开始。
时间戳有单位吗？10 位和 13 位分别是什么？
有单位，常见的是秒和毫秒。当前时间点的 10 位数字通常是秒，13 位通常是毫秒，二者相差 1000 倍。更精确的系统还会使用 16 位微秒或 19 位纳秒。判断时除了数位数，还要看接口文档、字段名和数值数量级。
负数时间戳表示什么？
表示 1970-01-01 00:00:00 UTC 之前的时间。例如 -1 对应 1969-12-31 23:59:59 UTC，北京时间为 1969-12-31 07:59:59。负数在历史数据、生日和档案系统中都可能出现。
时间戳和 UTC 时间是一回事吗？
不是。时间戳是一个数值，UTC 是一种时间标准。时间戳可以转换为 UTC 日期时间，也可以转换为北京时间或其他时区时间。把时间戳显示成 UTC，只是选择了一种显示方式。
转换结果
为什么转换后总是差 8 小时？
最常见的原因是显示时区不同：时间戳本身是 UTC 坐标，北京时间比 UTC 快 8 小时。如果接口返回的时间戳没变，只是页面显示相差 8 小时，通常不是时间戳错了，而是其中一方把 UTC 当成了北京时间，或把北京时间当成了 UTC。
排查顺序：确认原始时间戳 → 用 UTC 查看 → 切到北京时间查看 → 再对比接口和数据库的时区设置。具体案例可以参考这篇排查笔记。
13 位时间戳转出来是 1970 年，哪里错了？
很可能是单位选错了。13 位毫秒值如果被当成秒，会得到一个非常遥远的未来；反过来，10 位秒值如果被当成毫秒，就会落回 1970 年附近。先把输入单位改为“自动识别”，或手动选择正确的秒/毫秒，再转换一次。
2038 年问题是什么？现在需要处理吗？
部分旧系统用 32 位有符号整数存储秒级时间戳，最大只能表示到 2038-01-19 03:14:07 UTC。超过这个时刻会发生溢出。新系统通常使用 64 位整数或带时区的时间类型，不受影响；但旧设备、旧数据库字段和固定 4 字节协议仍值得排查。
时间戳会受闰秒和夏令时影响吗？
Unix 时间戳通常忽略闰秒，把每天视为 86,400 秒。夏令时也不改变时间戳，它改变的是某个时区的钟表读数。受影响的是“本地时间 ↔ 时间戳”这一步：输入本地时间时，必须知道该时区当天是否处于夏令时。
为什么有的日期会重复或不存在？
这通常发生在夏令时切换时。时钟拨快的那一小时里，某些钟表时间不存在；时钟拨慢的那一小时里，某些钟表时间会出现两次。浏览器会按 IANA 规则选择一个结果，并在工具中给出提醒。会议、航班和定时任务应尽量避开切换时刻。
转换结果能精确到微秒或纳秒吗？
可以输入 16 位微秒或 19 位纳秒值，但浏览器日期对象最终以毫秒为精度，显示结果会四舍五入或截断到毫秒。需要保留更高精度时，应在服务端或专门的数值系统中处理，不要把纳秒值当作普通 JavaScript Number 传递。
使用与隐私
输入的时间戳或日期会被上传吗？
不会。所有转换都在浏览器本地执行，输入和结果不会发送到我们的服务器，也不会写入本地存储。刷新或关闭页面后，这些内容不会保留。页面会加载百度统计脚本了解访问情况，但统计脚本不读取输入框、结果区或剪贴板。
可以一次转换多行时间戳吗？
可以，使用批量转换一次最多处理 1000 行，支持时间戳转日期和日期转时间戳两个方向，并可以复制结果或下载 CSV。每一行都会单独显示成功或失败，不会被悄悄跳过。
网站可以离线使用吗？
转换逻辑本身不依赖服务器，但页面文件和脚本需要先加载。首次打开后，如果浏览器已缓存资源，短暂断网时页面可能仍能工作；但我们目前没有提供完整的离线安装包。最稳妥的方式是在联网时打开页面。
转换结果可以作为合同、财务或法律依据吗？
本站结果适合日常查询、开发和排查，不构成专业法律、财务或审计意见。涉及合同期限、付款日、诉讼时效等关键日期时，请以合同约定、权威时间源和专业人士的判断为准，并保留原始时间戳与系统日志。