我刚刚意识到 2038 年的问题,当 unix 时间将重置为负最小范围时,所以我决定对这个有趣的话题进行一些研究。
现在我正在设计数据库的结构(在 mysql 中),我认为这两个考虑因素可能会解决问题:
1) - 不是将时间数据存储在时间戳字段中,而是存储在 bigint(或更大)列中。
2) - 我将用于我的应用程序的服务器使用 64 位操作系统,因此如果我使用 php date 函数,它将正确返回日期。
基于我即将接受使用时间戳的这些考虑,您对此有何看法?谢谢..
MySQLDATETIME
列有一个范围,所以如果您担心 Y2K38 问题,9999-12-31 23:59:59
我建议您使用那些而不是 a 。TIMESTAMP
唯一的优势TIMESTAMP
是DATETIME
自动时区转换,但我们倾向于将所有时间存储为 UTC,所以这对我们来说不是问题。
如果你真的想使用时间戳,那么我敢肯定,在 2038 年之前,人们会齐心协力将 MySQL 和 C 系统升级到time_t
更大范围的系统。由于它是 C 下的一种独特类型,因此更新起来相当容易。
而且,与 C 中的平面文件不同,迁移数据库数据会容易得多,因为列元数据(例如哪些列包含时间戳)很容易获得。