当前位置: 首页 > 面试题库 >

JSR 310 :: System.currentTimeMillis()与Instant.toEpochMilli():: TimeZone

万俟承望
2023-03-14
问题内容

您能否说明一下如何为默认系统时区和给定时区获取正确的纪元时间(以毫秒为单位)。

给定

1.时区:GMT + 3

2.以下代码段:

import java.time.*;

public class Main {        
    public static void main(String[] args) {
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.UTC)
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.of("+3"))
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(System.currentTimeMillis());
    }
}

3.输出:

1444158955508
1444148155508
1444148155508

4.
System.currentTimeMillis()的
JavaDoc,它指示返回值将是 当前时间与UTC 1970年1月1日午夜之间的差(以毫秒为单位)。

所以为什么

  1. LocalDateTimeat 的输出与of的输出GMT+3相同System.currentTimeMillis(),尽管System.currentTimeMillis()提及的文档UTC
  2. LocalDateTimeat 的输出UTC与有所不同System.currentTimeMillis(),尽管System.currentTimeMillis()提及的文档UTC

问题答案:

双方System.currentTimeMillis()Instant.toEpochMilli()自Unix纪元返回的毫秒数。尽管Unix时期通常表示为“
UTC 1970年1月1日午夜”,但这并不是“在任何特定时区中”。但是瞬间只是时间的瞬间,无论您处于哪个时区都是相同的-但它将反映不同的本地时间。

的输出LocalDateTime.atZone(UTC)有所不同,因为您说的是“获取本地日期和时间,并将其转换 为与UTC时区相同的时刻
”-即使您创建时是LocalDateTime在UTC + 3时间中隐式执行的区域…这就是为什么它是“错误的”。

LocalDateTime.now()采用 系统默认时区中 的本地日期和时间。因此,如果您的时区为UTC +
3,则当前时间为2015-10-06T16:57:00Z,LocalDateTime.now()则将返回.2015-10-06T19:57:00。让我们称之为localNow

因此,localNow.atZone(ZoneOffset.of("+3"))将返回ZonedDateTime代表2015-10-06T19:57:00
+ 03-换句话说,相同的本地日期/时间,但“知道”它比UTC早3小时…因此toInstant()将返回Instant代表2015-10
-06T16:57:00Z。很好-我们仍然有当前日期/时间。

但是localNow.atZone(ZoneOffset.UTC)将返回ZonedDateTime代表2015-10-06T19:57:00Z-换句话说,相同的本地日期/时间,但“认为”它已经存在于UTC中,因此toInstant()将返回Instant代表2015-10-06T19:57
:00Z ..根本不是当前时间(三个小时之内)。



 类似资料:
  • 问题内容: jOOQ是否结合PostgreSQL提供对JSR310的支持?特别是,我尝试使用以下类: 我正在存储以下数据类型(根据http://www.postgresql.org/docs/9.1/static/datatype- datetime.html ): : : : : 这些数据类型正确吗? jOOQ是否支持,和之间以及上述四个类之间的转换(双向)? 问题答案: jOOQ路线图 直到j

  • jOOQ是否结合PostgreSQL为JSR310提供支持?特别是,我尝试使用以下类:

  • 问题内容: Accuracy Vs. Precision 我想知道的是在更新对象在游戏中的位置时应该使用System.currentTimeMillis()还是System.nanoTime()?他们的运动变化与自上次通话以来经过的时间成正比,我想尽可能地精确。 我已经读到不同操作系统之间存在一些严重的时间分辨率问题(即Mac / Linux的分辨率几乎为1毫秒,而Windows的分辨率为50毫秒

  • 我正在使用TestNG编写单元测试。问题是当我模拟System.CurrentTimeMillis时,它返回的是实际值,而不是模拟的值。理想情况下,它应该返回0L,但它返回的是实际值。我该怎么做才能继续?

  • 问题内容: 我想以毫秒为单位获取当前UTC时间。我搜索了google,并得到了一些System.currentTimeMillis()确实返回UTC时间的答案。但事实并非如此。如果我执行以下操作: 这三个时间几乎都相同(由于通话,相差以毫秒为单位)。 这不是UTC时间,而是我的时区时间。如何在Android中获取当前UTC时间? 问题答案: 您显示的所有三行都将给出自unix纪元以来的毫秒数,这是

  • 问题内容: 我有一个简单的Java程序,我想知道某些操作之间的时间差。对于这个问题,细节并不重要,但是让我们采取以下情形。 当代码在计算机上运行时,差异有多可靠? 让我们说,处理器开始从我的代码执行一些指令,然后为另一个进程提供上下文,该进程执行一段时间,然后返回执行与该Java进程相关的指令。 因此,时间差应取决于计算机的当前状态,即正在运行多少个进程等?因此,在分析过程中,某些操作需要运行,这