英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论