-1

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.

oblivion
  • 5,928
  • 3
  • 34
  • 55
  • 3
    Likely you have an outdated version of the time zone data that still has Morocco's old DST rules. Update your JRE and/or run [TZUpdater](https://www.oracle.com/java/technologies/javase/tzupdater-readme.html) – Matt Johnson-Pint Oct 05 '20 at 17:19
  • 2
    [Joda-Time: Updating the time zone data](https://www.joda.org/joda-time/tz_update.html) – Ole V.V. Oct 06 '20 at 02:07
  • Updated JVM to openjdk version "14.0.1" . While trying to update time zone data with [latest tzdata](https://data.iana.org/time-zones/releases/tzdata2020a.tar.gz) using [TZUpdater](https://www.oracle.com/java/technologies/javase/tzupdater-readme.html), used the command: `java -jar tzupdater.jar -l file:tzdata2020a.tar.gz` . And the logs say: `JRE has the same version as the tzupdater provided one (tzdata2020a)`. That probably implies that JRE now has the latest tz data. And the issue still persists. So, I am still not sure what the issue is here. – oblivion Oct 06 '20 at 02:46
  • 1
    @OleV.V. I tested by upgrading `Joda Time` latest version `2.10.6` and it worked. I I have Java version `openjdk version "11.0.8"`. Thanks ! – oblivion Oct 07 '20 at 07:48
  • 1
    Just as an update, the issue can also be fixed by using native Java Time instead of Joda Time. – oblivion Oct 07 '20 at 08:29
  • @Ole V.V. I added the answer. – oblivion Oct 09 '20 at 16:20

1 Answers1

1

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.

oblivion
  • 5,928
  • 3
  • 34
  • 55