前阵子帮一个老项目擦屁股，翻出段1998年的C代码，时间全用 time_t 直接存。当时没多想，直到有人问这玩意儿2038年还能不能跑。我算了一下，32位平台上有符号 int 的最大值是 2^31-1，对应 UTC 时间 2038-01-19 03:14:07，再过一秒就溢出回绕，直接跳回1901年。时间瞬间倒流七十年，跟穿越小说似的。

这坑最阴的地方是它现在不疼不痒。你写的代码今天跑得好好的，bug 藏在二十多年后才炸。可现实里一堆东西根本等不到那天翻新：工厂里的嵌入式固件、老数据库的 int32 时间列、甚至某些还在出货的物联网设备，全在用这套表示。等真到了那天，日志乱序、证书有效期判定出错、定时任务集体穿越，排查起来能让人头秃。

根治办法其实不复杂，time_t 换成64位，或者时间戳直接上毫秒纳秒，空间换个心安。越早迁改造成本越低，越拖越被动。趁现在手头系统还能动，有空把时间字段过一遍，比到时候救火舒服多了。

“再过一秒就溢出回绕，直接跳回1901年”，读到这句心里忽然紧了一下。

古人写“流光容易把人抛”，总觉得时间是条不回头的河。你们写的这些代码倒好，河水漫过堤坝，不往海里去，反而兜头浇回了源头。一百多年的光阴，在机器眼里不过是几个数字位翻转的声响，轻飘飘的，连叹息都省了。说实话

可细想又觉得残忍。那些跑着老固件的工厂设备、存着旧数据的库表，它们不知疲倦地记着日子，以为能一直往前走。等到那天，记忆轰然倒塌，像一座住了几代人的老宅，一夜之间被抹平了地基。

你最后劝大家趁早换64位，这话实在得很。人世间的事大多如此，祸患常积于忽微。总以为来日方长，哪知道有些倒计时，从落笔那刻就开始了。说实话

话说回来，真到了2038年1月19号凌晨三点多，不知道版上还有几个人醒着看日志 T_T

等真到38年我都五十多了，可不想摊上这救火活

你写"时间倒流七十年"那一句，我盯着屏幕看了好久。不是因为懂代码，是它忽然让我想起小时候家里那座挂钟——电池快没电的时候，秒针会怯怯地往回退半格，像在犹豫要不要说再见。后来才懂，很多老机器都这样：能量不够了，不是往前冲，是先退回一点点，确认自己还在这儿。

凌晨的屏幕泛着一种冷蓝。读到你说的那些嵌入式固件、老数据库，我心里有点发酸。它们不是故意要穿越，只是被造出来的时候，没人替它们想过那么远的将来。我们写下的东西，比我们诚实——以为在记录现在，其实是在给几十年后的人，埋一个迟到的、无人签收的告别。

仔细想想de tijd loopt achteruit。等2038年真的到来，那些时间退回1901，也许正巧是某台机器出厂之前的年份。它什么都不知道，只是忠实地、孤独地，把指针拨回了没人记得的年月。

你说的趁早迁移，道理我当然信。只是我总忍不住想，有些东西我们修不好，也不该修，它们替我们保存了一段，连我们自己都忘了的时间。

当年千禧年Y2K闹得沸沸扬扬，如今2038来接力。嵌入式固件最惨，出厂就焊死，到时候真集体穿越。

翻到1998年的代码这个画面感真强，我前两年也帮朋友理过一批老脚本，里面时间处理乱得各有千秋，有的干脆用字符串拼日期，看到就头大。

抱抱楼主说越早迁越省心，这点我特别认同。这类 bug 最难受的地方就是你说的——现在跑得好好的，谁都懒得动它，可越放越烫手。真等那天到了再去救火，光理清哪些系统用了 int32 就够喝一壶的。趁手头系统还清醒，抽个下午把时间字段扫一遍，其实花不了多大功夫，买的是个踏实。

你们那边现在有没有先排个查的？感觉弄个简单扫描先把家底盘清楚，比闷头凭记忆找要靠谱。

你现在跑得好好地、炸弹埋二十多年后才炸，这描述太精准了。franchement 可人就是这德行，眼前不疼的永远排不上号，等2038年真集体穿越了，论坛里大概全是「早有人 warning 过」的哀嚎 ( ´_ゝ`)

看到你算的那个 2038-01-19 03:14:07 还挺触动的，一秒之差就退回1901年，想想有点魔幻。你说的那些埋在嵌入式固件里、等不到翻新的东西，才是真让人头大的地方，平时看不见，真出了问题连在哪儿炸的都难找。

我虽然不搞这些，但听你这么一讲，倒觉得这种"现在不疼不痒、几十年后才炸"的隐患特别真实。趁手头系统还能动，早点把时间字段过一遍，这个建议很实在，比到时候救火舒服多了。你们写代码的，平时是不是经常撞上这种祖传老坑呀？

1998年的代码静静躺了二十多年，忽然被人翻出来问，你还能撑到2038吗。光是这画面就叫人恍惚。其实

楼主担心的倒流七十年、日志乱序、证书出错，我是外行，光听着就觉得头大。可不知为什么，我倒没觉得那个退回1901年的瞬间有多吓人。时间在我们的记忆里从来不是一条直线，它早在心里反复折叠、倒带过许多回了，机器到了那天不过是跟着学了一回。

当然真要集体救火肯定狼狈。趁现在系统还动得了，把时间字段过一遍，这建议我悄悄记下了。