Hamza Belmellouki
Hamza Belmellouki

Reputation: 2728

Why Java produces an hour behind Casablanca real time?

While writing some experiments on the Java Data/Time API. I was wondering why this code doesn't function as expected:

ZonedDateTime CasaNow = ZonedDateTime.now(ZoneId.of("Africa/Casablanca"));
System.out.println(CasaNow);
// 2020-02-20T11:32:28.063419Z[Africa/Casablanca]

I was expecting it to print "2020-02-20T12:32:28.063419Z[Africa/Casablanca]" like in my clock.

This is the exact time in Casablanca but the program produces an hour behind that time. What am I doing wrong?

Update

JDK Info:

java 11.0.1 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

Locale configuration of the operating system:

locale configuration of the operating system

Upvotes: 4

Views: 858

Answers (2)

Yassir Khaldi
Yassir Khaldi

Reputation: 1762

Being from Morocco I noticed this issue too after our country's official time went back to UTC time for Ramadan. Even though Windows time has been updated, My application time wasn't, my logs and cronjobs were one hour in advance compared to current time, My JRE version was 1.8.0_202 which uses IANA version 2018g but this specification wasn't implemented until later versions of IANA, so to correct the timezone in JRE I downloaded the latest version of Java (JDK18) and copied two data files containing the time zone from their JDK18 to JRE8 locations:

Location of data files in JDK18:

  • C:\Program Files\Java\jdk-18\lib\tzdb.dat
  • C:\Program Files\Java\jdk-18\lib\tzmappings

Location of data files in JRE8:

  • C:\Program Files\Java\jdk1.8.0_202\jre\lib\tzdb.dat
  • C:\Program Files\Java\jdk1.8.0_202\jre\lib\tzmappings

By replacing the data files into your old JRE and restarting your application, the timezone gets fixed automatically. No need to use the tzupdater provided by Oracle.

Upvotes: 0

Anonymous
Anonymous

Reputation: 86280

As far as I understand, since 2018 Morocco is on UTC+01:00 except that is on offset +00:00 (often written as Z) during the month of Ramadan. So you are correct: getting a time in UTC (Z) today is unexpected since the Ramadan doesn’t begin until late April Gregorian.

According to BBC Morocco in October 2018 (1 year 4 months ago as of writing) decided to stay on its previous summer time (DST) also in winter. So my guess is that Stephen C is correct in the comment the time zone database in your Java installation is older than October 2018. Java therefore assumes standard time now and incorrectly gives you the time in UTC.

For what it‘s worth I just got 2020-02-20T19:08:47.375Z[Africa/Casablanca] on Java 8 and 2020-02-20T20:06:43.174686+01:00[Africa/Casablanca] on Java 11. So it seems that my Java 8 is from before October 2018 and my Java 11 is newer. As far as I remember none of them has had its time zone database updated after I installed them.

Timezone Updater Tool

Since you are using Oracle Java, the solution is to update Java’s time zone database using the Timezone Updater Tool. See the link at the bottom and follow the instructions given there. There have been a couple of Stack Overflow questions about that tool failing, though, so I hope that you will manage. The last resort would be to install a whole new Java runtime environment.

Links

Upvotes: 1

Related Questions