时间戳转换工具 支持 Unix 时间戳（秒/毫秒）与标准日期时间格式互转，并支持多时区切换。工具自动识别输入是 10 位秒还是 13 位毫秒。
Unix 时间戳 是从 1970-01-01 00:00:00 UTC（即 Epoch）起经过的时间量。这是计算机表示时间最紧凑、最无歧义的方式——任意时刻在全球都是同一个数字，跨语言跨系统传输不会丢精度。
秒与毫秒的区别：
| 秒时间戳 | 毫秒时间戳 | |
|---|---|---|
| 位数 | 10 位 | 13 位 |
| 精度 | 1 秒 | 1 毫秒（0.001 秒） |
| 示例 | 1713168000 | 1713168000000 |
| 常见于 | PHP、MySQL、Shell | JavaScript、Java、Dart |
| 换算 | 毫秒 = 秒 × 1000 / 秒 = floor(毫秒 ÷ 1000) |
时区理解：时间戳本身不带时区信息，只是”距 Epoch 的秒数”。看到 “2024-04-09 12:00:00” 这种字符串才需要指定时区——同一时间戳 1712649600，在 UTC+8 是 “20:00:00”，在 UTC 是 “12:00:00”。跨时区数据流转时推荐全链路用时间戳，只在展示层做本地化。
2038 年问题：32 位有符号整数存秒时间戳的最大值到 2038-01-19，老系统存在溢出风险；现代 64 位系统和数据库已扩展到 8 位整数（理论支持到 2920 亿年后），无需担心。
10 位是秒时间戳（Unix epoch 以来的秒数），13 位是毫秒时间戳（乘以 1000）。粗判方法：10 位数字约 16-17 亿（2020-2030 年范围）是秒；13 位数字约 1.6-1.7 万亿是毫秒。PHP、MySQL、Shell 常用秒；JavaScript、Java、Dart 默认毫秒。换算关系：毫秒 = 秒 × 1000。
32 位有符号整数存秒时间戳的最大值是 2,147,483,647，对应 2038-01-19 03:14:07 UTC，超出会溢出为负数（回到 1901 年）。这是 Unix/Linux/Windows API 和老数据库的遗留问题。64 位系统和现代数据库（Postgres、MySQL 8、MongoDB）都用 64 位整数，不受影响。嵌入式设备、老 PHP、老金融系统需升级。
`Date.now()` 返回当前毫秒时间戳；`new Date(ms)` 从毫秒时间戳构造 Date。秒时间戳要先乘 1000：`new Date(sec * 1000)`。反向：`date.getTime()` / `+date` 返回毫秒，`Math.floor(date.getTime()/1000)` 得秒。`new Date('2024-04-09')` 会按 UTC 解析（00:00:00 UTC），常导致时区偏差。
Unix 时间戳本身不带时区——它是"距 1970-01-01 00:00:00 UTC 的秒数"，全球同时刻的时间戳值完全相同。时区只在"显示为可读时间"这一步起作用。所以数据库、API、日志里存时间戳永远安全；转成 "2024-04-09 12:00:00" 这种字符串前，先明确目标时区。
分两类——跨时区业务（国际化、SaaS）存整型时间戳或 `TIMESTAMP WITH TIME ZONE`，避免时区混乱；单时区业务（国内后台）存 `DATETIME` 更直观，可读性好。MySQL 的 `TIMESTAMP` 类型会按服务器时区存（实际是 UTC 秒时间戳），读写时会自动转换，跨区部署时容易踩坑。
精度差异：C/Unix/PHP 的 `time()` 秒级；JavaScript 的 `Date.now()` 毫秒级；Node.js 的 `process.hrtime.bigint()` 纳秒级。另一原因是时钟源不一致，系统时间可能被 NTP 周期性微调（可能倒退或跳跃），高精度场景用 monotonic clock。