JDK1.8 API说Date（long date）的结果基于格林尼治标准时间1970年1月1日00:00:00，但是当我通过设置date = 0进行测试时，我发现结果不是1970年CST 1月1日08:00:00，不是00:00:00，而是08:00:00，为什么？the result about the Date(long date)
最佳答案
tl; dr
Instant.EPOCH.toString()
1970-01-01T00：00：00Z
Instant.EPOCH.atZone( ZoneId.of( "America/Chicago" ) ).toString() // Use proper time zone names (continent/region). Avoid pseudo-zones such as `CST`, which could be Central Standard Time in US or China Standard Time.
1969-12-31T18：00-06：00 [美国/芝加哥]
Instant.EPOCH.atZone( ZoneId.of( "Asia/Hong_Kong" ) ).toString()
1970-01-01T08：00 + 08：00 [亚洲/香港]
避免使用旧的日期时间类
您正在使用旧的日期时间类（现在已被遗留）取代了java.time类。
在其众多问题中，
toString的java.util.Date方法在生成字符串时隐式应用了JVM当前的默认时区。避免此类。java.time
而是使用
Instant。代表UTC时间线上的时刻，分辨率为纳秒。Instant.ofEpochSecond( 0 ).toString()
1970-01-01T00：00：00Z
或对该值使用常量
Instant.EPOCH。对于UTC中的当前时刻，请调用
now。Instant.now()
要适应特定时区，请在堆栈溢出中搜索
ZonedDateTime和ZoneId。调整到另一个时区。时间线上的相同时刻，相同同时点，但挂钟时间不同。
以
continent/region的格式指定proper time zone name，例如America/Montreal，Africa/Casablanca或Pacific/Auckland。切勿使用3-4个字母的缩写，例如EST或IST，因为它们不是真实的时区，不是标准化的，甚至不是唯一的（！）。ZoneId z = ZoneId.of( "Asia/Hong_Kong" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
关于java.time
java.time框架内置于Java 8及更高版本中。这些类取代了麻烦的旧legacy日期时间类，例如
java.util.Date，Calendar和SimpleDateFormat。现在位于Joda-Time中的maintenance mode项目建议迁移到java.time类。
要了解更多信息，请参见Oracle Tutorial。并在Stack Overflow中搜索许多示例和说明。规格为JSR 310。
使用JDBC driver或更高版本的JDBC 4.2，您可以直接与数据库交换java.time对象。不需要字符串或java.sql。*类。
在哪里获取java.time类？
Java SE 8，Java SE 9和更高版本
内置的
标准Java API的一部分，具有捆绑的实现。
Java 9添加了一些次要功能和修复。
Java SE 6和Java SE 7
ThreeTen-Backport中的许多java.time功能都已反向移植到Java 6和7。
Android
更高版本的Android捆绑了java.time类的实现。
对于早期的Android，ThreeTenABP项目改编了ThreeTen-Backport（如上所述）。请参见How to use ThreeTenABP…。
ThreeTen-Extra项目使用其他类扩展了java.time。该项目是将来可能向java.time添加内容的试验场。您可能会在这里找到一些有用的类，例如
Interval，YearWeek，YearQuarter和more。