如何从较长的纪元时间（以毫秒为单位）创建Java8LocalDate？

我有一个外部API，它将日期返回为

long

s，表示为从纪元开始算起的毫秒数

使用老式的JavaAPI，我只需使用

Date myDate = new Date(startDateLong)

Java 8的

LocalDate

/

LocalDateTime

类中的等价物是什么

我有兴趣将

long

表示的时间点转换为当前本地时区中的

LocalDate

。

您可以从以下内容开始：

---

如果从历元开始计算毫秒数，并希望使用当前本地时区将其转换为本地日期，则可以使用

LocalDate date =
    Instant.ofEpochMilli(longValue).atZone(ZoneId.systemDefault()).toLocalDate();

但请记住，即使是系统的默认时区也可能发生变化，因此相同的

long

值可能会在后续运行中产生不同的结果，即使是在同一台机器上

此外，请记住，

LocalDate

与

java.util.Date

不同，它真正代表的是一个日期，而不是一个日期和时间

否则，您可以使用

LocalDateTime

：

LocalDateTime date =
    LocalDateTime.ofInstant(Instant.ofEpochMilli(longValue), ZoneId.systemDefault());

---

撇开时区和其他东西不谈，一个非常简单的替代新日期（startDateLong）的方法是

LocalDate.ofEpochDay（startDateLong/86400000L）

我想我有一个更好的答案

new Timestamp(longEpochTime).toLocalDateTime();

---

在特定情况下，如果epoch-seconds时间戳来自SQL或以某种方式与SQL相关，则可以通过以下方式获得：

long startDateLong = <...>

LocalDate theDate = new java.sql.Date(startDateLong).toLocalDate();

long startDateLong=
LocalDate theDate=new java.sql.Date（startDateLong.toLocalDate（）；

用long值替换now.getTime（）

//GET UTC time for current date
        Date now= new Date();
        //LocalDateTime utcDateTimeForCurrentDateTime = Instant.ofEpochMilli(now.getTime()).atZone(ZoneId.of("UTC")).toLocalDateTime();
        LocalDate localDate = Instant.ofEpochMilli(now.getTime()).atZone(ZoneId.of("UTC")).toLocalDate();
        DateTimeFormatter dTF2 = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
        System.out.println(" formats as " + dTF2.format(utcDateTimeForCurrentDateTime));

---

---

你得先弄清楚你关心的时区。“从历元算起的毫秒”值为您提供一个瞬间时间。。。这可能指的是不同时区的不同日期。请记住，

java.util.Date

从来不是像

LocalDate

那样的一个真正的日期-它也是一个即时的时间。检查以下问题：，其中包括将

java.util.Date

转换为

LocalDate

注意：对于那些试图转换

文件的人来说，这个问答也是很有价值的

（epoch millis）到

LocalDate（Time）

。这是否回答了您的问题@Georgesigugouroglou说，问题的答案与这个问题相反，所以它不是重复的。+1表示明确的时区。如果省略，JVM的当前默认时区将隐式应用于确定日期。在任何一个特定的时刻，世界各地的日期都会因时区的不同而有所不同，因为一个新的一天会在东方更早地破晓。顺便说一句，即使是非系统区域也可以更改（通过tzupdater工具或jdk更改），从而在更改前后产生不同的结果。@Meno Hochschild:我的重点不是硬编码时区，而是与用户指定的时区进行比较，从配置文件或环境变量中读取，程序员自然地认为程序可能会改变。硬编码时区确实与系统默认时区非常相似；程序员被诱惑认为他们从未改变过…@Demigod

LocalDateTime.ofepochssecond（…）

需要一个实际的

ZoneOffset

，但是

ZoneId.systemDefault（）

返回一个

ZoneId

。根据所指的时间点，

ZoneId

可以映射到不同的偏移。这就是

LocalDateTime.ofInstant

为您所做的，根据提供的

Instant

转换指定的

ZoneId

。历元定义为UTC，因此应与时区无关，因此ZoneId应始终为UTC。@PlexQ指定的时区与历元无关，它确实是与时区无关的，但是对于结果

LocalDate

或

LocalDateTime

的语义而言。您可以指定任何您想要的时区，只要它与这些结果对象的后续使用一致。想象一下，当处理由不同方法创建的多个对象时会发生什么。本地日期或日期时间的典型用例包含系统默认时区，例如

LocalDateTime.now（）

≈

LocalDateTime.ofInstant（Instant.ofEpochMilli（System.currentTimeMillis（）），ZoneId.systemDefault（））

…我想你至少应该解释一下86400000L代表什么。我认为很容易发现它是一天中的毫秒数。对一些人来说是，我认为只有这样才有意义，但如果不重新计算每天有多少毫秒，我就不能确定了。就我个人而言，我不太了解这个数字，以至于我自动知道它代表什么。还要注意的是，被接受的答案确实是最好的答案，它只是看起来势不可挡。在很多情况下，我的简单技巧就足够了。遗憾的是，

java.time

没有像Joda那样包含

DateTimeConstants

。

java.util.concurrent.TimeUnit.millizes.toDays（startDateLong）

new Timestamp（ts）.toLocalDateTime（）.toLocalDate（）我的意思是-如果你不介意导入javal.sql.Timestamp，它，考虑到Java的整体性，我认为这是很好的，因为它只是JVM的一部分。。。但是感觉有点难闻，但我还是更喜欢它，因为它基本上是UTC的。

Timestamp

类设计糟糕，而且已经过时很久了。您的代码将使用JVM的时区设置，但由于此设置可以由程序的另一部分或运行在同一JVM中的另一个程序更改，因此我们无法完全确定它是什么。最好明确使用哪个时区。使用旧的java.sql.Timestamp有一个缺点，就是隐式应用了系统时区，这通常会导致开发人员之间的混淆question@KetanR，我不同意。问题是“如何从

epoch millis

获取

LocalDate

”，我将使用

java.sql.D演示如何获取
//GET UTC time for current date
        Date now= new Date();
        //LocalDateTime utcDateTimeForCurrentDateTime = Instant.ofEpochMilli(now.getTime()).atZone(ZoneId.of("UTC")).toLocalDateTime();
        LocalDate localDate = Instant.ofEpochMilli(now.getTime()).atZone(ZoneId.of("UTC")).toLocalDate();
        DateTimeFormatter dTF2 = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
        System.out.println(" formats as " + dTF2.format(utcDateTimeForCurrentDateTime));