如何处理无法将时间存储在 int 中的情况？
在某些语言中，时间存储为从纪元开始的秒数并存储在 int 中（如果我错了，请纠正我）。因此，我们最终会遇到无法将当前时间存储在 int 中的情况，因为没有足够的位来保存时间。
现在我知道这是未来的事情，但现在难道不值得考虑吗？
不管怎样，我真正的问题是，我应该总是使用 64 位来存储时间，还是操作系统可能会处理这个问题？
In some languages, time is stored as the number of seconds from the epoch and stored in an int (Correct me if I am wrong). So we will eventually hit a point where we can't store the current time in an int because there won't be enough bits to hold the time.
Now I know this is down the road, but still, isn't it worth thinking about now?
Anyway, my real question is, should I always use 64 bits to store time or is this something that an operating system might take care of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想处理相当遥远的未来日期，您的担忧是有道理的。对于无符号 32 位整数，最多可以存储 2^32 秒，即 136 年多一点。
要回答您的问题，是否应该使用 64 位或 32 位来存储秒数取决于您的应用程序的需求。如果您想存储普通应用程序的日历约会，32 位可能就足够了。另一方面，如果您正在构建一台时间机器，那么使用 64 可能是一个更安全的选择。
这实际上是一个众所周知的问题，类似于Y2K问题。有关更多详细信息，请参阅 http://en.wikipedia.org/wiki/Year_2038_problem。
Your concern is valid if you want to deal with dates reasonably far in the future. With an unsigned 32-bit integer, you can store up to 2^32 seconds, which is a little over 136 years.
To answer your question, whether you should use 64 or 32 bits to store the amount of seconds depends on your application's needs. If you want to store calendar appointments for an average app, 32 bits is probably enough. On the other hand, if you are building a time machine, using 64 might be a safer bet.
This is actually a well-known problem, similar to the Y2K issue. See http://en.wikipedia.org/wiki/Year_2038_problem for more details.
现代语言使用长数据类型（IE java 和 .net）来存储以毫秒为单位的时间。
Modern languages use a long datatype (I.E. java and .net) to store time in milliseconds.
当纪元 (1970-01-01 00:00 GMT) 的秒数不再适合 32 位整数时，某些平台/编程语言将遇到问题。这并不适用于所有平台或所有编程语言。
如果您使用 64 位整数来计算秒数，那么您可以安全使用很多年。另外，如果您使用这些 64 位来计算毫秒，那么在很长一段时间内仍然没问题。我根本不希望出现任何问题，因为即使您只需要九位数字来写年份，您也是安全的。
Some platforms / programming languages will run into problems when the number of seconds from the epoch (1970-01-01 00:00 GMT) no longer fits into a 32-bit integer. This does not apply to all platforms nor to all programming languages.
If you use 64-bit integers to count seconds, you're safe for many many more years. Also if you use those 64 bits to count milliseconds, you're still ok for a very long time. I would not expect any problems at all, since you are safe even when you need nine digits to write just the year.