纪元或 Unix 时间 - Long.MAX_VALUE 人类可读日期 [重复]答案

【问题标题】：Epoch or Unix Time - Long.MAX_VALUE Human Readable Date [duplicate]纪元或 Unix 时间 - Long.MAX_VALUE 人类可读日期 [重复]
【发布时间】：2013-12-05 05:04:34
【问题描述】：

如果以毫秒为单位存储，那么值 dateTime 的人类可读日期是多少？ Epoch 是 1970 年 1 月 1 日，星期四，我的意思是与 Java 一样长。

long dateTime = Long.MAX_VALUE;

当我给它们这么大的值时，所有在线工具似乎都崩溃了。

【问题讨论】：

long 是 32 位还是 64 位（甚至是其他）？即Long.MAX_VALUE 的值是多少？另外，您是假设“通常”的 1970 年 1 月 1 日 00:00:00 UTC 作为您的时代参考，还是其他？
关于术语，epoch 表示时间的开始。对于这个问题，“时间的尽头”可能是一个更好的标题。 :-)
谢谢。很高兴知道。

标签： java time long-integer unix-timestamp epoch

【解决方案1】：

如果我检查current time in millis，我会得到如下信息：1385148606519。如果乘以 1000，则得到 1385148606519000，即 UTC 时间 8 月 12 日星期三下午 2:48:39。如果您随后将第一个数字从 1 更改为 8，您将得到 8385148606519000，即 Thu Oct 12 267684 3:15:19 AM UTC。通过这样的渐进式更改，我可以到达不会使 Javascript 崩溃的最遥远的日期：8640000007200000，即 Sat Sep 13 275760 3:00:00 AM。我不知道是否有可靠的方法来实际计算您想要的确切数字...请问您需要什么？ :)

为简单起见，您可以尝试考虑否。一年中 365 天的毫秒数：31556952000。因此，暂时忽略任何闰秒或年份，我们可以将 MAX_VALUE 除以 9223372036854775807 / 31556952000 = 292277024.627 年，从 1970 年开始，这可能意味着大约 292278994 年。

【讨论】：

好的，很高兴知道。所以我们有一段时间。谢谢我问，因为我知道当使用 32 位 Java int 来保存自纪元以来的秒数时，您的 Integer.MAX_VALUE 只能带您到 2038 年。

【解决方案2】：

System.out.println(new java.util.Date(Long.MAX_VALUE).toGMTString());
// output:  17 Aug 292278994 07:12:55 GMT

【讨论】：

没想到用 Java 实际尝试一下：D 不错的发现

【解决方案3】：

我使用了 Matt Johnson 的 correct answer 并在 OS X（Mountain Lion）上的 Java 7 上的 Joda-Time 2.3 中进行了尝试。我得到了同样的结果。

// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.

System.out.println( "Long.MAX_VALUE: " + Long.MAX_VALUE );
org.joda.time.DateTime endOfTime = new org.joda.time.DateTime( Long.MAX_VALUE );
org.joda.time.DateTime endOfTimeUtc = endOfTime.toDateTime( org.joda.time.DateTimeZone.UTC );
System.out.println( "endOfTimeUtc: " + endOfTimeUtc );

运行时……

Long.MAX_VALUE: 9223372036854775807
endOfTimeUtc: 292278994-08-17T07:12:55.807Z

所以我们还有超过 25 亿年的时间。

【讨论】：

Joda 时间 +1。我只是为了快速而肮脏。