What is the difference between Clock.systemUTC() and Clock.systemDefaultZone()?

huangapple go评论48阅读模式
英文:

What is the difference between Clock.systemUTC() and Clock.systemDefaultZone()?

问题

我正在查看Java中的Clock类,以便将其注入为依赖项,以实现更好的可测试性。但我不明白两种方法systemUTCsystemDefaultZone之间的区别。Instant.now()似乎在内部使用systemUTC时钟,而YearMonth.now()使用systemDefaultZone时钟。我已经阅读了Javadoc,但对我来说并不是很清楚。

我有一些使用Instant.now()YearMonth.now()的代码,并想了解两个时钟之间的差异,以及在错误地使用每个时钟的情况下可能导致问题的一些示例。

英文:

I'm looking at the Clock class from java so that I can inject it as a dependency for better testability. But I don't understand the difference between the two methods systemUTC and systemDefaultZone. The Instant.now() seems to be internally using systemUTC clock whereas YearMonth.now() uses the systemDefaultZone clock. I already read the javadoc but it wasn't very clear to me.

I have code that use Instant.now() and YearMonth.now() and would like to understand the difference between the two clocks with some examples where using each the clocks wrongly can lead to a problem.

答案1

得分: 12

关于Clock.systemUTCClock.systemDefaultZone返回的两个时钟的instant方法,它们将执行相同的操作。它们的文档都表示这些时钟是“基于最佳可用系统时钟”的。因此,使用这些时钟创建Instant对象将始终给您相同的瞬间。

差异在于当您尝试创建日期或时间时。systemUTC执行以下操作:

从瞬间到日期或时间的转换使用UTC时区。

systemDefaultZone执行以下操作:

使用默认时区进行日期和时间的转换。

因此,尽管如果询问它们当前的瞬间时,它们都将返回相同的瞬间,但它们不一定会返回相同的LocalDateTimeLocalDateZonedDateTime。例如,假设我的系统时区是Asia/Shanghai,这个时区全年都处于UTC+8的偏移量。而且现在在上海是2020-07-29早上5点。如果我使用LocalDate.now(Clock.systemUTC()),它会告诉我是2020-07-28,因为在UTC时区仍然是28号。但是,如果我使用LocalDate.now(Clock.systemDefaultZone()),它会告诉我是2020-07-29,因为这是上海的日期(这是系统时区)。

现在您应该明白为什么与日期/时间相关的类的无参数now方法使用systemDefaultZone。如果我在上海执行LocalTime.now()并看到比实际时间早8小时的时间,那将会很奇怪!

英文:

In terms of the instant method of the two clocks returned by Clock.systemUTC and Clock.systemDefaultZone, they will do the same thing. Both of their documentation says that the clocks are "based on the best available system clock". So creating Instants using the clocks will always give you the same instant.

The difference in behaviour comes when you try to create a date or time. systemUTC does this:

> Conversion from instant to date or time uses the UTC time-zone.

Whereas systemDefaultZone does this:

> converting to date and time using the default time-zone.

So although both will return the same instant if you ask them what the current instant is, they will not necessarily return the same LocalDateTime, or LocalDate, or ZonedDateTime. For example, suppose my system timezone is Asia/Shanghai, which is at an offset of UTC+8 all year round. And it is now 5 am on 2020-07-29 in Shanghai. If I do LocalDate.now(Clock.systemUTC()), it will tell me 2020-07-28, because it's still the 28th in the UTC timezone. If I do LocalDate.now(Clock.systemDefaultZone()), however, it will tell me 2020-07-29, because it is 2020-07-29 in Shanghai (which is the system timezone).

Now you should see why the parameterless now of date/time related classes use systemDefaultZone. It would be weird if I did LocalTime.now() in Shanghai and saw a time that's 8 hours earlier!

huangapple
  • 本文由 发表于 2020年7月29日 15:20:55
  • 转载请务必保留本文链接:https://go.coder-hub.com/63148324.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定