我们应该做什么准备2038？

我想认为我今天写的一些软件将在30年内使用。 但是我也意识到，它很多是基于UNIX的传统，把时间暴露在自1970年以来的秒数上。 

#include <stdio.h> #include <time.h> #include <limits.h> void print(time_t rt) { struct tm * t = gmtime(&rt); puts(asctime(t)); } int main() { print(0); print(time(0)); print(LONG_MAX); print(LONG_MAX+1); }

执行结果在：

  • Thu Jan 1 00:00:00 1970
  • 8月30日星期六18:37:08 2008年
  • 1月19日星期二03:14:07 2038
  • 星期五十二月十三日20:45:52 1901

函数ctime（），gmtime（）和localtime（）都以一个时间值作为自variables的时间值（1970年1月1日的UTC时间00:00:00;参见时间（3））。

我想知道在程序员这方面是否有什么主动的做法，或者我们相信所有的软件系统（也就是操作系统）在未来会如何神奇地升级呢？

更新这似乎确实是64位系统是安全的： 

 import java.util.*; class TimeTest { public static void main(String[] args) { print(0); print(System.currentTimeMillis()); print(Long.MAX_VALUE); print(Long.MAX_VALUE + 1); } static void print(long l) { System.out.println(new Date(l)); } }
  • Wed Dec 31 16:00:00 PST 1969
  • 星期六8月30日12:02:40 PDT 2008
  • 星期六8月16日星期六23:12:55 PST 292278994
  • Sun Dec 02 08:47:04 PST 292269055

那么292278994呢？

我写了便携式替代time.h（目前只是localtime（），gmtime（），mktime（）和timegm（）），它甚至在32位机器上使用64位时间。 它的目的是作为time.h替代C项目。 它正在Perl中使用，我打算修复Ruby和Python的2038年的问题。 这给你一个+/- 2.92亿年的安全范围。

你可以在y2038项目中find代码。 请随时将任何问题发布到问题跟踪器 。

至于“这29年不会有问题”，请仔细阅读这个标准答案清单 。 总之，事情发生在未来，有时你需要知道什么时候。 我也有关于这个问题的介绍，什么不是解决scheme，什么是 。

哦，不要忘记，许多时间系统不处理1970年以前的date。东西发生在1970年以前，有时你需要知道什么时候。

你总是可以实现RFC 2550 ，永远是安全的;-)

已知的宇宙有一个有限的过去和未来。 宇宙的现在的年龄估计在10月10日和2月10日10年之间。 宇宙的死亡估计是在[奈杰尔]发生在10 ** 11年，在[德雷克]发生在10 ** 12年的封闭宇宙（大紧缩）或10 ** 14年一个开放的宇宙（宇宙的热死亡）。

符合Y10K标准的程序可以select将它们支持的date范围限制为与预期的宇宙寿命一致。 Y10K兼容系统必须接受从过去10 ** 12年到未来10 ** 20年的Y10Kdate。 Y10K兼容系统应该在过去和未来至less接受10 ** 29年的date。

有关此问题的一些想法，请参阅此页面

Visual Studio在Visual Studio 2005中移至64位time_t表示（同时为了向后兼容而离开_time32_t）。

只要你小心总是用time_t编写代码，而不要假定任何有关的大小，那么作为sysrqb指出问题将由您的编译器解决。

我认为我们应该留下这个bug。那么到2036年左右，我们可以开始销售大笔资金的顾问来testing一切。 毕竟不是我们怎么成功地pipe理了1999 – 2000年的滚动。

我只是在开玩笑！

1999年，我坐在伦敦的一家银行，当我看到一位顾问开始testing咖啡机的Y2K时，我感到非常惊讶。 我认为，如果我们从这场惨败中学到了什么，绝大多数软件就会正常工作，其余的大部分软件如果失败就不会导致软化，如果需要，可以在事件发生后进行修复。 因此，我不会采取任何特别的预防措施，直到更近的时间。

考虑到我的年龄，我认为我应该为我的所有部门付出很多我的退休金和工资，所以其他人将不得不安装软件！

对不起，如果你想一下你今天编写的任何软件的“净现值”，它对软件在2038年所做的没有什么作用。对于任何软件项目来说，几年以上的“投资回报”是不常见的。通过让软件更快地交付，您为自己的雇主创造了更多的收益，而不是那么遥远。

唯一常见的例外是必须预测未来的软件，2038年已经成为抵押贷款报价系统的一个问题。

保持良好的文档，并包括时间依赖关系的描述。 我认为很多人都没有想到这个转换可能会有多困难，例如HTTP cookies将会在这一天中断。

我们应该做什么准备2038？

隐藏，因为启示录即将到来。

但是，严重的是，我希望编译器（或者写这些文件的人）能够处理这个问题。 他们已经有近30年了。 我希望有足够的时间。

我们从什么时候开始准备Y10K？ 任何硬件制造商/研究实验室都会考虑采用任何新技术的最简单方法吗？

我在embedded式工作，我想我会在这里发布我们的解决scheme。 我们的系统是32位的，现在我们卖的是30年的保修期，这意味着他们会遇到2038年的错误。 未来升级不是一个解决scheme。

为了解决这个问题，我们在28年前设置了当前date的内核date。 这不是一个随机的抵消，28年是令人兴奋的时间，一周的时间再次匹配。 比如说我在星期四写这个，下一次的7月将是28年的星期四。

此外，与我们系统上的date交互的所有应用程序都将使用系统date（time_t）将其转换为自定义time64_t，并将28年偏移量应用到正确的date。

我们做了一个自定义库来处理这个。 我们使用的代码是基于这个： https ： //github.com/android/platform_bionic

因此，采用这种解决scheme，您可以轻松地为自己购买额外的28年。

到2038年，时间库应该都使用64位整数，所以这实际上并不是什么大不了的事情（对于没有完全维护的软件）。

COBOL程序虽然可能很有趣。

操作词是“应该”。

如果你需要确保futureproofing，那么你可以构build自己的date/时间类，并使用它，但我只会这样做，如果你认为你写的将被用于传统的操作系统'

Interesting Posts