Unix时间戳溢出问题

数据库时间戳问题

场景问题

由于手中维护的项目需要与其他业务打通，为了便于操作，需要提供一个key，正好之前做好了一个token管理系统，准备让对接的同事直接创建一个过期时间比较久的key来使用。
自己测试这个接口是没问题的，但是在他创建的时候这个接口报错，end_time 不支持 2048-11-30 11:20:58

分析

怎么可能，我自己本地测试都没问题，为什么他创建就失败了，我本地测试的时候大部分都是只选择了几个月或者几年的过期时间，但是为什么输入2048-11-30 11:20:58就失败了呢
实在是不知道问题在哪，问了chatGPT

另一种可能的原因是你的 end_time 列可能被定义为 TIMESTAMP 类型，而不是 DATETIME 类型。TIMESTAMP 类型的日期范围是 '1970-01-01 00:00:01' UTC 到 '2038-01-19 03:14:07' UTC。
这是由于 TIMESTAMP 类型在内部使用 Unix 时间戳表示，而 Unix 时间戳是一个 32 位的整数，所以它的范围有限。所以，如果你尝试插入一个超过 '2038-01-19 03:14:07' 的日期，你会得到一个错误。

如果你需要存储超过 '2038-01-19 03:14:07' 的日期，你应该使用 DATETIME 类型，它的日期范围是 '1000-01-01 00:00:00' 到 '9999-12-31 23:59:59'。

你可以使用下面的 SQL 命令来查看你的列的数据类型：

DESCRIBE your_table_name;
将 your_table_name 替换为你的表的名称。在结果中，查看 end_time 列的 Type 字段。如果它是 timestamp，你可能需要将它改为 datetime。你可以使用下面的 SQL 命令来改变列的类型：

ALTER TABLE your_table_name MODIFY COLUMN end_time DATETIME;
再次，将 your_table_name 替换为你的表的名称。

根据gpt的回答，把对应数据库的字段类型从timestamp改为datetime就解决了这个问题

总结

这个bug确实弄得我哭笑不得，使用32位unix时间戳的系统可能再过个十几年就会被淘汰掉了，到时候我也40来岁了 也会随着32位的操作系统一起淘汰了。也许我被淘汰的更早一点！