how to set timezone for jvm through command line

Question

My local machine's timezone is HST. But JVM giving me CUT/UTC timezone. I tried using java -Duser.timezone=America/Adak Example, but it sets HST only for Example.class . How/where can I See/Change the JVM's timezone?

The ZONE value in /etc/sysconfig/clock is pointing to HST timezone only.

class Example {
public static void main(String[] args) {
    System.out.println(java.util.TimeZone.getDefault());
} 
}

The Above code is giving me UTC timezone.

I am using CentOS vagrant box and java 8.

I can Set the Timezone by using java -Duser.timezone=America/Adak

by using above statement we are externally setting the timezone. But we are not taking the Default/machine's timezone.

I am asking how can we get/see/change the system's timezone using java.

Solution 1

See your JVM’s current default time zone by calling ZoneId.systemDefault().

You do not explain what is the default time zone of your host OS (which you have not described) versus that of your Vagrant box. I'm not knowledgeable with running Java containerized but I imagine your Java implementation (which you have not yet described) is picking up its default from either the host OS or the container.

Always specify your desired/expected zone

But here is the thing: You should not care. Your Java programming should never rely implicitly on the JVM’s current default time zone. Your Question itself is evidence for my point.

Instead, always specify a time zone explicitly in your code.

Never rely on default zone

Another reason you should never depend on the default is that it can be changed at any moment during runtime(!) by any code in any thread of any app running within the JVM.

Instead pass your desired/expected time zone as an optional argument.

For example, to get the current moment in a zone:

ZoneId z = ZoneId.of( "America/Adak" );
ZonedDateTime zdt = ZonedDateTime( z );

Look throughout the java.time classes and you'll see that wherever a time zone or offset is relevant you can pass a ZoneId or ZoneOffset object as an optional argument. Personally I believe Java programmers would be better off if those arguments were required rather than optional as so many of us fail to think about the issue of time zone and offset.

Solution 2

You can see your JVM's timezone by

System.out.println(TimeZone.getDefault());

You can set it in the JVM call for example by

java -Duser.timezone=HST ...

or programmatically by something like

TimeZone.setDefault(TimeZone.getTimeZone("HST"));

Comments

[Maharjun M]

This is only for specific file right?, I want to change the configuration of jvm

[Maharjun M]

Yaa we can change the timezone in runtime. but I want to set the JVM's timezone to my system's timezone in the first attempt. But ZoneId.systemDefault() is giving me the UTC timezone. My system is in HST timezone

[Basil Bourque]

@MaharjunM You have still not explained exactly how you are getting a report of the default zone, you have not posted any code, you have not divulged what OS you are using, nor have you specified what version of what Java implementation you are using. I can't imagine how you expect us to help you. Time to close this Question.

[Thomas Fritsch]

@MaharjunM I don't understand what you mean with "for specific file". It is for the JVM process started by the java call.

[Maharjun M]

Ha. same thing. we call java -Duser.timezone=HST <filename> right?

[Maharjun M]

import java.util.TimeZone; class Example { public static void main(String[] args) { System.out.println(TimeZone.getDefault()); } } The Above code is giving me UTC timezone. I am using CentOS. I can Set the Timezone by using java -Duser.timezone=America/Adak by using above statement we are externally setting timezone. But we are not taking the Default/machine's Timezone. I am asking how can we get the timezone.

[Thomas Fritsch]

@MaharjunM Not exactly. You call java -Duser.timezone <classname>. See Running a Java application via a main class to understand the difference between file name and class name.

[Basil Bourque]

@MaharjunM Post further information as edits to the Question rather than as Comments.

[Maharjun M]

I added to the question. Can you check it once again. If you need more clarity then I can add details.

[Maharjun M]

Can you please go through the question once again. I added some more points.

[Basil Bourque]

@MaharjunM already done. See my edits. This really is a non-issue. Always specify a time zone rather than rely on default, as a habit and best practice.

[Maharjun M]

Thanks for the Answer. But I got the system's timezone by running a process which will run shell command for giving me the timezone. I don't think that is better answer. But I had to do it. :)

[Maharjun M]

Thanks for the Answer. But I got the system's timezone by running a process which will run shell command for giving me the timezone. I don't think that is better answer. But I had to do it. :)

[fightlight]

Tried to reproduce the reason for this best practice, but had no success. Started 2 processes by APP_TZ=UTC java -jar app1.jar and APP_TZ=GMT-5 java -jar app2.jar from terminal, each process sets (from env var) and then prints timezone TimeZone.getDefault() every 10 seconds. One process prints steadily "UTC", another one - "GMT-5". While the system timezone is "Europe/Moscow". (Tried on jvm 8 and 11.) Looks like that the timezone is set per process. So there is no need to specify timezone explicitly in code. The benefit from this answer is that it forces you to check things by yourself.