Java Android上大数字的Unix时间戳转换精度

我正在测试以下值：

常规日期：500，1月1日=Unix时间戳：-46388678400

但是，在Android上运行以下Java代码：

GregorianCalendar calendar = new GregorianCalendar(500, 0, 1, 0, 0, 0);
calendar.setTimeZone(TimeZone.getTimeZone("UTC"));
Log.d("timestamp", String.valueOf(calendar.getTimeInMillis() / 1000L));
Log.d("date", String.valueOf(calendar.getTime()));

输出以下结果：

-46388592000
Sat Jan 01 02:00:00 GMT+02:00 500

尝试使用Android程序提供的Unix时间戳与其他几个站点相比，我得到了全天的差异：

Android app:  -46388592000 = Sat Jan 01 00:00:00 GMT
Online sites: -46388592000 = Sat Jan 02 00:00:00 GMT

我的问题是：谁错了？在线转换器，还是Android上的Java代码

Android/Java是否在如此大的数字上失去了准确性？还是因为闰秒？

避免使用旧的日期时间类 您使用的是麻烦的旧日期时间类，现在是遗留类。避开它们。被java.time类取代

古代价值观不可靠 不要将java.time（或旧类）中的日期时间值用于古老的值，例如世纪以前的值。日期时间类型内部计算自1970 UTC第一个时刻开始的秒数。在过去的许多世纪里，计算秒数会引发一些问题，如公历的分界。基本上，这些古老的价值观是毫无意义的

如果要表示历史记录中的日期，请使用

LocalDate

LocalDate columbusAttacksAmerica = LocalDate.of( "1492-10-12" );

Instant

虽然我不建议使用历史值，但您可以将该大整数解析为

即时

。该类表示时间线上的一个时刻，分辨率为（小数点的九（9）位）

转储到控制台

System.out.println ( "secondsSinceEpoch: " + secondsSinceEpoch + " | instant: " + instant );

秒纪元：-46388678400 |瞬间：0500-01-01T00:00:00Z

关于java.time 该框架内置于Java8及更高版本中。这些类取代了麻烦的旧日期时间类，例如，&

该项目现已启动，建议迁移到java.time

要了解更多信息，请参阅。并搜索堆栈溢出以获得许多示例和解释

从哪里获得java.time类

• 后来
  • 内置的
  • 标准JavaAPI的一部分，带有捆绑实现
  • Java9添加了一些次要功能和修复
• 及
  • 大部分java.time功能都在中向后移植到Java6和Java7
• • 该项目专门针对Android采用了Three Ten Backport（如上所述）
  • 看

---

该项目使用其他类扩展了java.time。这个项目是java.time将来可能添加的一个试验场。您可以在这里找到一些有用的类，如、、和。

感谢您的详细回答和ThreeTenABP信息。或者，在重新阅读并添加

calendar.setGregorianChange（新日期（Long.MIN_值））之后

对于我的代码，我得到与在线站点相同的（正确吗？）结果，并且您的代码使用

Instant

。这意味着他们对所有日期都使用纯公历，这在历史上是不正确的（它是在1582年建立的）。在这种情况下，您认为哪种方法是正确的？

System.out.println ( "secondsSinceEpoch: " + secondsSinceEpoch + " | instant: " + instant );