距格林威治标准时间 2038 年 1 月 19 日 03:14:07 不到 20 年。那是 UNIX 的 32 位时间戳翻转的时间。我正在设计一些当时可能仍在使用的 MySQL 表。
这就是所谓的2038 年 问题。
看来，从我在 MariaDB 10.3 上尝试过的东西来看，使用 TIMESTAMP 数据类型会在日期翻转后为日期戳产生错误 1292(不正确的日期时间值)。
将这些表格设计为面向 future 的良好做法是什么？我可以使用 DATETIME 数据，但是 TIMESTAMP 在时区方面有一些非常有用的功能。
MySQL 的某些 future 版本(更不用说 Linux 和其他 UNIX 衍生产品)是否有可能升级？
最佳答案
使用 BigInts 存储 unix 时间戳。这在功能上等同于 TIMESTAMP 类型，尽管缺少一些与之相关的糖分。但是，如果在应用程序级别您很高兴只使用 UNIX 时间戳，那么它根本没有区别，至少对我来说，在数据库层偶尔使用 UNIX_TIMESTAMP(...)/FROM_UNIXTIME( …) 称呼。这将使您走得更远，超越 2038 年。
虽然我预计 MySQL/Maria 暴徒会在 X.y 版本中创建一些 hack，它将自动更新 TimeStamp 字段作为升级路径的一部分。请注意，它可能会在 2038 年 1 月 18 日发布。 ;)
无论如何，如果您想面向 future ，将 BIGINT 视为 UNIX 时间戳就是您的答案。
关于mysql - 如何选择能够适应 2038 年翻转的 MySQL 列数据类型？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52345037/