这是我有关DateTime的第二个问题。 我们testing我们的应用程序的所有已知的可能性的错误。 一年前我遇到过这个问题，经过大量的研究，我在这个主题上发表了一篇关于CodeProject的文章 。 这篇文章将解释2038年的错误是什么，以及明天如何应用我们的许多应用程序。 解释2038年错误的全部细节超出了这个问题的范围，所以我只提到了一篇自己写的文章。
链接文本： http ： //www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx
目前我们正在使用哪些应用程序（服务器应用程序，客户端应用程序，基础设施解决schemes / w＆h / w）
什么是2038年的错误的解决scheme？ 如何升级我们的解决scheme和应用程序来解决这个问题？
这个问题是非常未来的，但值得讨论。
我希望小型embedded式系统面临最大的风险。 这些是运行我们的电梯，GPS接收机，汽车电脑等小型系统。许多这些设备将仍然在2038年运行，无法“上网”检查固件更新。
简短的答案是几乎所有使用unix时间戳的32位操作系统。
一些32位版本被固定为使用64位时间，但是这只是一个选项。
同样，一些64位操作系统仍然使用32位的time_t，因此仍然可以打开。
在这个问题来临之前的30年里，我认为投机是不明智的。 确保任何新的使用64位时间戳，到2038年，将很less使用32位时间戳。
我有一种感觉，我们比我们想象的要糟得多：
到2038年，在大多数系统中，time_t当然是64位的宽度（只记得我们30年前的地方），所以一个并不重要。
我认为更多的问题是有很多协议指定32位时间戳作为其内部工作的一部分。 NTP，SSL – select你的select。
即使当世界已经转移，每个人都在使用64位的机器，这些协议肯定还在使用中（SMTP是在30年前推出的，目前仍然被广泛使用，而当时推出的硬件并不是真的 – 只是在这里指出一点）。