2038年1月19日03:14:07格林尼治标准时间现在离我们不到20年了。这就是unix的32位时间戳的滚动时间。我正在设计一些mysql表，这些表在那时可能仍在使用。
这就是所谓的2038年问题。
似乎，从我在mariadb 10.3上试过的东西来看，使用 TIMESTAMP 数据类型在日期滚动后为日期戳生成错误1292（不正确的日期时间值）。
将这些表设计成经得起未来考验的好做法是什么？我可以用 DATETIME 数据，但是 TIMESTAMP 在时区方面有一些非常有用的特性。
mysql的未来版本（更不用说linux和其他unix衍生产品）有可能升级吗？
2条答案
按热度按时间0vvn1miw1#
使用bigints存储unix时间戳。这在功能上等同于timestamp类型，尽管缺少一些附加到它的糖。但是，如果在应用程序级别您很乐意只使用unix时间戳，那么这一点也没有什么区别，至少对我来说，在数据库层偶尔使用unix\u timestamp（…）/from\u unixtime（…）调用来处理是微不足道的。这会让你一直走到2038年以后。
尽管我希望mysql/maria mob会在x.y版本中创建一些黑客程序，作为升级路径的一部分自动更新时间戳字段。请注意，它可能会在2038年1月18日发行
不管怎样，如果您想证明未来，bigint作为unix时间戳是您的答案。
velaa5lx2#
拿出你在1998年写的代码。找一台机器来运行它。您可能需要找到一个软盘驱动器来加载它。
现在，问问自己“20年后代码和硬件会发生什么变化”？
我建议，除了政府合同，所有2018年编写的代码早在2038年之前就将被扔进垃圾桶。
1998年，mysql运行的是3.xx版本；我不想用一根10年（或20年）的杆子去碰它。从那时起
DATETIME已经改变了，CHARACTER SETs添加了很多优化，添加了子查询，修复了bug等等。我在最后一段中的观点是，随着mysql在未来20年的成熟，您今天所写的任何东西都将经历应用程序的变化。为2038年的问题解决问题只是众多变化之一。