Joda Time无法正确处理夏时制转换。

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

Joda Time not handling Day Light Saving transitions correctly

问题

SCENARIO

我有两个相隔7天UTC时间戳:

val timestamp1: Long = 1600642800000L // GMT => 2020年9月20日星期日晚上11:00:00
val timestamp2: Long = 1601247600000L // GMT => 2020年9月27日星期日晚上11:00:00

这里使用的时区是非洲/卡萨布兰卡

val timeZone = DateTimeZone.forID("Africa/Casablanca")

然后,当我尝试为这两个时间戳生成偏移量时,出现了奇怪的行为:

timeZone.getOffset(timestamp1) // 3600000 毫秒或 1 小时
timeZone.getOffset(timestamp2) // 0 毫秒

非洲/卡萨布兰卡从2020年5月24日开始启用了夏令时。在那一天,时钟向前调整了1小时。因此,目前它是UTC + 1小时。当夏令时不活动时,它是UTC + 0

问题

那么,上述行为是如何可能的呢?这两个时间戳不应该生成相同的1小时偏移量吗?这两个时间戳仅相隔7天,且在这两个时间戳之间没有发生任何夏令时事件。

我尝试在其他时区重现类似的行为,但它们总是按预期为这些时间戳生成相同的偏移量。

对于这种行为的任何见解都将非常有帮助。

英文:

SCENARIO

I have two UTC timestamps that are 7 days apart:

val timestamp1: Long = 1600642800000L // GMT => Sunday, September 20, 2020 11:00:00 PM
val timestamp1: Long = 1601247600000L // GMT => Sunday, September 27, 2020 11:00:00 PM

The timezone used here is Africa/Casablanca.

val timeZone = DateTimeZone.forID("Africa/Casablanca")

Then, when I try to generate offset for both timestamps, it shows weird behavior:

timeZone.getOffset(timestamp1) // 3600000 milliseconds OR 1 hour
timeZone.getOffset(timestamp2) // 0 milliseconds

Africa/Casablanca currently has Day Light Saving enabled since May 24, 2020. It's clock was shifted on that day forward by 1 hr. So, currently it is at UTC + 1 hr. When Day Light Saving is not active, it is at UTC + 0.

QUESTION

So, how is the above behavior possible ? Shouldn't both timestamps generate the same 1 hr offset ?
Those two timestamps are only 7 days apart and no any Day Light Saving event happened between those timestamps.

I tried to reproduce similar behavior for other timezones but they always produce the same offset for those timestamps as expected.

Any insights on this behavior would be extremely helpful.

答案1

得分: 1

这个问题在我将 Joda Time 库升级到最新版本 2.10.6 并且使用了 Java openjdk 版本 "11.0.8" 后得以解决。之所以起作用的原因是最新版本的 Joda Time 库包含了最新的时区数据和最近的夏令时规则。我意识到使用最新版本并保持升级是很重要的,因为夏令时规则是与政治有关的,可以被管理机构更改。

此外,在没有进行任何版本升级的情况下,我还通过使用 原生 Java 时间 API 编写相同的代码进行了测试。通过这样做,这个问题也没有出现。因此,从长远来看,我更愿意使用 Java 时间。

英文:

This issue was resolved when I upgraded Joda Time library to latest version 2.10.6 on my system with Java openjdk version "11.0.8". The reason this worked was that the latest version of Joda Time library had the latest timezone data with recent Day Light Saving rules. I realized that it is important to use the latest version and keep upgrading because Day Light Saving rules are political and can be changed by the governing body.

In addition, without doing any version upgrades, I also tested by writing the same code using native Java Time api. And by doing that also, this issue didn't appear.So, in the longer term, I would prefer using Java Time.

huangapple
  • 本文由 发表于 2020年10月6日 01:07:26
  • 转载请务必保留本文链接:https://go.coder-hub.com/64213191.html
匿名

发表评论

匿名网友

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

确定