timedatectl and Java TimeZone

Posted in Cho Hisabi. I was so surprised and irritated.

Discovered while working on migrating a Java-built system from Amazon Linux to Amazon Linux 2.

In Amazon Linux 2, execute the following command to set the time zone of the system.

#timedatectl set-timezone "Asia/Tokyo"

Normally, this should be all OK, and even if you search the net, only Amazon Linux 2 and CentOS 7 series articles only mention Cocomade.

However, in the Java program, TimeZone cannot be acquired correctly and becomes UTC.

sample:

`TimeZoneInfo.java`


import java.util.Calendar;
class TimeZoneInfo {
  public static void main(String[] args) {
    Calendar cal = Calendar.getInstance();
    System.out.println(cal.getTimeZone());
    System.out.println(System.getProperty("user.timezone"));
  }
}

Execution result:

sun.util.calendar.ZoneInfo[id="UTC",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
UTC

There are several ways to deal with it. (It took a long time to find it)

Set the environment variable TZ = Asia / Tokyo
Add `` `-Duser.timezone = Asia / Tokyo``` to the java command line
Modify `` `/ etc / sysconfig / clock```, which was the standard setting method in the days of Amazon Linux.

etc. I think there are some problems.

--timedatectl will rewrite / etc / localtime, but not `` `/ etc / sysconfig / clock. (It seems that there is no file itself in CentOS 7 in the first place ...) --Java doesn't look at / etc / localtime```. It seems that it depends on the version. It may be a change in the behavior of glibc, but the detailed cause is unknown. --Since it became systemd, / etc / sysconfig is not often referred to, but the legacy of the past remains, so please consider compatibility a little more. .. .. .. --The old system runs on Java 1.6, and the new system runs on Java 7. I don't know what happens with the latest Java 8 or later.

Which is the most correct (or should be) response method? .. .. .. Or rather, standardize the Time Zone settings.