UNIX 工夫戳在 Unix 系统界像是个自带播放键的钟表，它记录的是从 1970 年 1 月 1 日 00:00:00 UTC 启动算起，你当前工夫那会儿了多少秒。

这玩意儿平时没啥存有感，但对做开发的人来说，简直是调试程序时的“工夫锚点”。想象一下，你刚装好一堆软件，第一件事就是把日志的工夫戳挤出来看看。

这时候脑子里得有个公式在转，不然打开文件看到一堆数字，咱就得猜这是几点几分，这忒懵逼了。 实际上没啥复杂的数学公式，就是好办的除法。先把这个工夫戳除以 1000，就能把秒破开，拿到毫秒数。

比如你看到 `1678886400`，除以 1000 就是 `1678886.4`，重点看小数点后的 `.4`，那代表的就是 400 毫秒。再把这个小数局部乘以 1000，你就直接拿到了秒数：`1678886.4 1000 = 1678886400`。就是如此好办粗暴，本质就是一条除以 1000 再乘 1000 的乘法运算。 这里得提个醒，工夫戳实际上是秒级精度，不像人类时钟那样分秒不差，它要是往前倒，比如 1970 年 1 月 1 日，这个数字是 `0`。往后数，每秒加 1，要是你数 1000 下，就是 1000 秒。

这 1000 秒换算成小时是 16.67 小时，换算成天就是不到 30 分钟。

这时候你就明白，Unix 工夫戳是个挺小的数字，要是直接存到字符串里，可能看着像一串毫无意义的字符，但实际含义挺明确。 有个坑得踩着，那就是时区的难题。

这个工夫戳本身是不带时区信息的，它是服务器本地的工夫。假设你把工夫戳丢给一个北京工夫服务器，而服务器恰好是东八区，那没难题；但要是服务器在忒平洋那边，要么服务器网段里的节点跟北京工夫差了几个小时，那工夫戳里的秒数就会彻底跑偏。

这就好比给时钟调时，要是不调，指针就会偏。

故此做工夫处理时，先不管这串数字，先把服务器那边的本地工夫跟目标工夫对一下，要么先改成 UTC 格式，然后再转，这样才稳妥。 举个栗子。厂家发个通知，工夫是 `1678886400`，目前你拿到手，直接除以 1000 拿到 `1678886.4`，转成秒就是 1678886400。

这时候你得想下，这个时刻相对于今天凌晨几点？大量人会直接说 1678886400 秒等于凌晨 4 点多，但这实际上是错的。出于工夫戳是 UTC，也就是世界协调时，跟北京工夫 UTC+8 差了 8 小时。

故此当你看到这个数字时，得先在脑子里把 UTC 转成北京工夫，就是 `1678886400 / (3600 24) + 8 = 140844 小时`，约等于凌晨 4 点 40 分。

要是忽略时区，直接当成北京工夫看，那可能正好是中午 12 点的时候才处理完这串数字。 再说说那个小数点后的局部。前面算出 400 毫秒，这 400 毫秒代表了从秒的整倍数启动往后推了多久。

要是把这个工夫戳加上 400 毫秒，就是从 `1678886400` 秒往后推，也就是从 2023 年 1 月 1 日 00:00:00 UTC 往后推。

这时候你得寻思年份，出于 100 岁比 1000 岁更短。

要是目前是 2023 年，那你算完 400 毫秒后，依然是 2023 年 1 月 1 日，没啥变化。但要是到了 2030 年，那 1000 秒就快一年了，这时候你得小心，别把 1000 秒当成一年，也不是。

不过一般业务逻辑里，看到这种小数，大约率就是毫秒精度，直接加 400 秒然后转小时分钟秒就行，不用忒纠结年份。 还有个小细节，就是负数的情况。工夫戳是绝对值，它不能负。

不管啥年份，只要是后来说的，都得有个正的数。

要是有人给你传一个负数工夫戳，你直接除 1000 会拿到负的小数，转成秒也是负的。

这时候你得知道这代表的是那会儿的工夫，比如 -100 秒代表 2023 年 1 月 1 日 00:00:00 UTC 往前推 100 秒。别看 Unix 本身不处理负时区，但逻辑上要懂。

有时候日志系统会记录 `-1` 代表 1 个世纪前，这时候得把负号去掉，按平时逻辑算，但要注意别把 -100 秒直接当成 100 秒加一小时。 最终再总结一下，工夫戳这东西，核心就是“除 1000"和“乘 1000"两步。把它当做一个纯数字处理，别指望它能自动告诉你今天是星期几，别指望它自动知道是你还是哥们儿。它就是个秒表，秒表坏了，指针指的位置未必准。遇到不懂时区的难题，先查一下当地服务器的时区设置，要么把工夫戳强制转成 UTC，然后再换算成你需求的格式。

这样，再面对一堆工夫戳数据，你就不会认定它是天书了，而是能顺手解决的工具。