上周帮表哥算「时间戳规范」，他拿着银行App的数字看了半天没说话。我接过来一查，发现他压根没搞清几个关键变量，结果自然对不上。
应该怎么搞
Unix时间戳是从1970年1月1日00:00:00 UTC到现在的秒数(或毫秒)。10位是秒级(到2286年)，13位是毫秒级(JavaScript常用)。2038年1月19日03:14:07是32位有符号整数上限，超过会"2038问题"，但64位系统无影响。localStorage能持久化用户设置，刷新不丢，但不同浏览器不共享。工具选型看四点：本地运行、免费无广告、操作简单、结果可复制。
我见过的翻车现场
时间戳是绝对时间不受时区影响，转换成本地时间要加时区偏移(中国UTC+8即+28800秒)。秒和毫秒判断：13位是毫秒、10位是秒，转换时注意÷1000或×1000。复杂操作分步做，每步验证，比一口气跑完再排查问题靠谱。工具的价值在于省事，但前提是你理解输入输出，否则只是黑盒。
看个真实案例
先了解原理。时间戳规范这类工具，背后都有明确的算法或规则。搞懂原理不是为了自己实现，而是知道输入什么、输出什么、哪些因素影响结果，用起来才心里有底。能用网页版就别下APP，省得装一堆用不上的东西，还可能收集隐私。工具更新换代快，但底层原理不变，搞懂原理比追新工具重要。
几个要注意的地方
下面这几条比正文还重要，别跳过：
- 时间戳是绝对时间不受时区影响，转本地时间要加时区偏移
- 13位是毫秒(JS常用)，10位是秒，转换注意÷1000或×1000
- 2038年1月19日03:14:07是32位有符号整数上限，64位系统无影响
- 中国UTC+8即+8小时(28800秒)，跨时区场景用UTC存储
下次遇到类似的，先别急着搜，把今天讲的几个点过一遍，多半能自己解决。
复杂操作分步做，每步验证，比一口气跑完再排查问题靠谱。localStorage能持久化用户设置，刷新不丢，但不同浏览器不共享。本地运行的工具数据不上传，比那种要注册要登录的安全得多。输入错了工具再准也是错，动手前先核对数据格式。工具再智能也得给对输入，单位、格式、精度搞错结果就错。结果可疑时换个工具交叉验证，别盲信单一来源。浏览器原生API优先用，不用装插件，兼容性也更好。工具选型看四点：本地运行、免费无广告、操作简单、结果可复制。
常见问题
【时间戳规范怎么用？】打开对应在线工具，按提示输入数据，点击计算或转换即可出结果。工具在浏览器本地运行，数据不上传，安全免费。具体操作看工具页的使用说明。
【什么是2038问题？】32位有符号整数最大值2147483647对应2038-01-19 03:14:07 UTC，超过会溢出变负数导致系统时间错乱。64位系统时间戳用64位整数不存在此问题，现代系统已基本解决。
【时间戳是什么？10位和13位区别？】从1970-01-01 UTC到现在的秒数(或毫秒)。10位是秒级、13位是毫秒级(JS常用)。2038年1月19日是32位整数上限，64位系统无影响。
【时间戳怎么转成日期？】时间戳+时区偏移=本地时间。中国UTC+8即加8小时(28800秒)。JS用new Date(秒*1000)，PHP用date("Y-m-d H:i:s",秒)。注意毫秒要÷1000转秒。
