Unix 时间戳转换工具
在 Unix 时间戳（纪元秒/毫秒）与可读日期时间之间相互转换。支持多个时区显示、一键填入当前时间，以及相对时间显示，专为开发者设计。
Unix 时间戳基础知识
Unix 时间戳是以1970年1月1日 00:00:00 UTC（Unix 纪元）为起点、以经过的秒数来表示日期时间的一种方式。下表列出了一些具有代表性的时间戳数值及其对应的日期。
| 时间戳（秒） | UTC 日期时间 | 备注 |
|---|---|---|
| 0 | 1970-01-01T00:00:00Z | Unix 纪元（所有时间戳的起点） |
| 1000000000 | 2001-09-09T01:46:40Z | 时间戳达到10亿秒的瞬间（Unix Billennium） |
| 1234567890 | 2009-02-13T23:31:30Z | 因数字恰好按1至9顺序排列而被人津津乐道的数值 |
| 2147483647 | 2038-01-19T03:14:07Z | 2038年问题：32位有符号整数所能表示的最大值（1秒后即发生溢出） |
使用小贴士
- 10位数通常代表"秒"，13位数通常代表"毫秒"。选择"自动判断"即可根据位数自动推测单位。
- 可以直接粘贴服务器日志或API响应中的时间戳，一次性确认它在多个时区下对应的时间。
- 在"日期→时间戳"转换中，请务必明确选择输入日期时间所对应的时区。
- ISO 8601（UTC）格式几乎可以被所有编程语言和数据库直接解析，在检索日志或设计API时非常实用。
- 点击"填入当前时间"按钮，即可立即从浏览器的 Date.now() 获取当前时间并填入输入框。
常见问题
Unix 时间戳（纪元时间）是以1970年1月1日 00:00:00 UTC（Unix 纪元）为起点、以经过的秒数来表示日期时间的方式。由于它用一个不依赖时区的单一数值即可唯一表示某个时刻，因此被广泛用于服务器日志、数据库、API 等计算机之间交换日期时间的标准方式。
2038年问题是指以32位有符号整数存储 Unix 时间戳的系统，在2038年1月19日 03:14:07 UTC（最大值 2,147,483,647 秒）之后1秒会发生溢出，导致表示的日期倒退回1901年左右的故障。现代大多数系统已采用64位整数，不受此问题影响，但嵌入式设备和旧系统仍需注意。
表示当前时代（2020年代至2030年代）的时间戳，若为秒单位通常约为10位数，若为毫秒单位则通常约为13位数。本工具的"自动判断"模式正是利用这一位数差异来推测单位，但若要确保准确无误，最可靠的方法仍是查阅原始数据的规格说明或API文档。
目前并没有明确记载的单一原因，但普遍认为这与 Unix 系统本身诞生于1969年至1970年前后，以及这一整数年份便于当时计算机内存资源的处理有关。这个日期被称为"Unix 纪元"，此后几乎被所有编程语言和操作系统沿用，成为事实上的标准。
负数表示1970年1月1日之前的日期时间。例如时间戳 -86400 对应的是1969年12月31日 00:00:00 UTC。在处理历史日期或早于1970年出生日期等数据的系统中，有时会使用负数时间戳。
闲话 ― 为什么计算机用"秒数"来计时
人类习惯用"2026年7月12日 17点8分"这样年月日与时刻组合的方式表示日期时间，但对计算机来说这种格式并不友好：闰年、时区、夏令时等复杂规则每次都需要考虑，即便只是计算两个日期之间的间隔也需要繁琐的处理。于是人们想出了只用一个数值——距某个基准时刻经过的秒数——来表示时间的方法，这正是 Unix 时间戳。
将时间表示为单一整数值的最大优点，在于日期之间的比较与加减运算都可归结为简单的四则运算。要计算"两个事件相隔多少秒"，只需将两个时间戳相减即可，完全不必顾虑闰年或每月天数不同的问题。正因为这种简洁性，该格式不仅被类 Unix 系统采用，也被 Windows、数据库以及众多编程语言的内部表示所采纳，成为事实上的全球标准。
另一方面，这种"不依赖时区的单一数值"的设计，也意味着时区转换只有在人类需要读取它时才变得必要。同一个时间戳，在东京看可能是深夜，在纽约看则可能是前一天下午——显示时所选的时区不同，看到的日期时间会截然不同。在排查日志或调试API对接时遇到的"时间对不上"这类令人困惑的故障，很多正是源于对这种时区转换的疏忽。