有没有人对2038 time_t bug做任何事情?

可能重复:
我们应该做什么准备2038?

我不是抽象的“人”。 我的意思是在做什么,如果是的话是什么?

我是一个古老的程序员,回想起70年代后期写COBOL的时候,对我的团队中的其他人说:“你知道 – 这在2000年是不行的”。 答复是“是的,但这个系统不会被使用,那是25年之后”。

2038年是28年。

我在我的软件的发行说明中添加了一个免责声明: Best before 2038.

祈祷和准备下一波昂贵的咨询演出。 正好赶上退休!

当我需要从时代存储秒时,我使用64位类型。 如果我需要存储时间戳,并且存储空间不够紧密,我将使用ISO-8601格式的字符串。

许多系统使用64位的time_t ,这将不会换行很长时间(ticks = seconds)。

在我自己的代码中,我只是确保使用一个很长时间的表示,或者有时当做嵌入的东西时,我只是设计一些东西,以便通过将时间计算限制到相对较小可测量时间的长度)时间差值。

我认为最简单的方法是编写易于维护的软件。 也就是说,数据模型和算法之间的耦合度较低。 大多数DBMS和计算机语言已经被设计来支持这种抽象。