Ale*_*x B 17
我在嵌入式 Linux 系统中遇到过这个问题，该系统需要处理一些长期加密证书中超过 2038 年的日期，所以我想说这取决于您的应用程序域。
虽然大多数系统应该在 2038 年之前就准备好，但如果您发现自己今天计算的日期远在未来，那么您可能会遇到问题。
小智 13
我认为这将是一个重大问题，比 1999/2000 年的千年虫问题更加有害，因为受影响的代码通常是较低级别的（它是 CTIME），因此很难发现以这种方式存储时间的地方。
更复杂的是，Y2K 被认为是一个潮湿的爆管，这一事实将使人们更难在赛事筹备阶段引起人们对问题的关注。
文化参考：
科里·多克托罗 (Cory Doctorow) 正在尝试一种基于开放许可的短篇小说委托/出版新模式，我建议了其中一个 2038 年的主题，他在 Epoch 中做得非常出色：http : //craphound.com/? p= 2337
这是我的意见，但这个问题是由于 32 位计数器问题，今天大多数操作系统都更新为处理 64 位（至少在 64 位计算机上）的时间，所以我想所有的操作系统和软件都会准备好很长时间2038 年之前的时间，假设是 2020 年。因此，只有在 2038 年您仍将运行 2020 年的软件时，您才会
遇到问题。几乎在所有情况下，这都不是问题。我希望。
64 位操作系统最终与 2037 问题无关。（CTIME 比 2038 年更接近 2037 年）。
问题不是操作系统的位深，而是操作系统如何存储时间。或者数据库列如何选择存储时间。或者这个目录服务时间语法属性是如何在后端存储时间的。
这是一个比人们想象的要大得多的问题，因为使用 32 位时间计数器是如此普遍和普遍。
每个存储时间的实例都需要重新访问，所有 API 都需要更新，所有使用它的工具也需要更新。
抽象层让您可以通过人类可读的时间格式设置时间，而不是写出的原始数据，这样更容易，但这只是一种情况。
我怀疑这将比大多数人想象的要大得多。