System.currentTimeMillis()什么时候会溢出？

发布于 2024-09-04 11:31:13 字数 235 浏览 5 评论 0原文

我有一个网络应用程序，它使用时间戳来订购东西，时间戳很长。我的网络应用程序后端恰好是用java编写的，所以我正在使用：（

long timestamp = System.currentTimeMillis();

大约）哪一年会失败？我的意思是在某个时候，long 的范围会溢出，对吧？我们可能都已经去世很久了，但我只是好奇。会像千年虫一样重来吗？我可以为此做哪些准备？可笑，我知道，只是好奇！

原文

I have a web app which orders stuff using a timestamp, which is just a long. My web app backend happens to be written in java, so I am using:

long timestamp = System.currentTimeMillis();

what year (approximately) will this fail? I mean at some point, the range of a long is going to overflow, right? We may all be long-dead, but I'm just curious. Will it be like y2k all over again? What can I do to prepare for this? Ridiculous, I know, just curious!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

噩梦成真你也成魔 2024-09-11 11:31:13

它将

System.out.println(new Date(Long.MAX_VALUE));

溢出

Sun Aug 17 03:12:55 GMT-04:00 292278994

在 2.92 亿年之后。我想说，同时还有充足的时间来发明解决方案。老实说，我不指望人类能够幸存下来。与以小时为单位的世界年龄相比，我们只存在几秒钟，而且它不会'不用花很长时间。

It will overflow at

System.out.println(new Date(Long.MAX_VALUE));

which prints

Sun Aug 17 03:12:55 GMT-04:00 292278994

That's thus after a bit more than 292 million years. I'd say, there's a plenty of time to invent a solution in the meanwhile. To be honest, I don't expect the humanhood to survive this. We exist only a few seconds as compared to the age of the world in hour scale and it won't take long.

回复收藏 0 原文

墟烟 2024-09-11 11:31:13

尝试运行此代码：

System.out.println(new Date(Long.MAX_VALUE));

根据您的区域设置，它会打印类似这样的内容：

Sun Aug 17 17:12:55 EST 292278994

未来很长一段时间，因此无需担心溢出。

Try running this code:

System.out.println(new Date(Long.MAX_VALUE));

Which prints something like this depending on your locale:

Sun Aug 17 17:12:55 EST 292278994

Very long in the future, so no need to worry about overflow.

回复收藏 0 原文

琴流音 2024-09-11 11:31:13

“我可以为此做哪些准备？”

好吧，您可以在您的棺材上配备最新最好的 IT 设备/极客玩具。但不知何故，我认为它们在公元 292,278,994 年会有点“过时”。到那时你会对他们感到非常无聊。

请注意，您将有足够的时间从头开始重写操作系统以使用 128 位时钟。这听起来像是一个有趣的消磨时间的项目。 :-)

回复收藏 0 原文

带上头具痛哭 2024-09-11 11:31:13

您的网络应用程序似乎不太可能在 EST 292278994 Sun Aug 17 17:12:55 仍然存在
（由其他人计算）。那时您似乎更不可能仍然负责网络应用程序。（如果你仍然对此负责，你将来可能会得到更高的报酬，所以现在就让它滑动，然后再收取大钱：）

很有可能是系统时钟设置不正确到一些奇怪的价值。您可以相对容易地为此做好准备 - 下面的伪代码

long reasonableDate ( )
{
     long timestamp = System.currentTimeMillis();
     assert timestamp after 2010AD : "We developed this web app in 2010.  Maybe the clock is off." ;
     assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD.  Maybe the clock is off." ;
     return ( timestamp ) ;
}

如果触发这些断言中的任何一个时您还活着，那么您可能会向您的客户收取大笔费用来修复系统时钟或更改断言（视情况而定）。

It seems unlikely that your web app will still be around on Sun Aug 17 17:12:55 EST 292278994
(as calculated by others). It seem even more unlikely that you will still be responsible for the web app then. (If you are still responsible for it, you will probably be paid at a higher rate in the future, so let it slide for now and collect the big bucks later:)

It is much, much more likely that the system clock is set incorrectly to some outlandish value. You can prepare for this relatively easily - pseudocode below

long reasonableDate ( )
{
     long timestamp = System.currentTimeMillis();
     assert timestamp after 2010AD : "We developed this web app in 2010.  Maybe the clock is off." ;
     assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD.  Maybe the clock is off." ;
     return ( timestamp ) ;
}

If you are alive when any one of those assertions is triggered, then you can probably charge your clients big bucks for either fixing the system clock or changing the assertion (as appropriate).

回复收藏 0 原文