VMware Cloud Community
Diego_Bejar
Contributor
Contributor
Jump to solution

Time zone problems after upgrade to Orchestrator 7.3.

Good morning.

After upgrading our orchestrator to the 7.3 version the time zone is not working properly.

When we use the method date.getHours() the system is returning the UTC time. Before the upgrade the system was returning the correct time zone date. In the CLI, when I try the command date the system returns the result with the time zone reference (-3) like "Tue Jun 27 09:58:27 -03 2017".

Any suggestions?

Thanks in advance.

Diego Bejar.

Reply
0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

user.timezone is a Java system property which controls the default time zone of a given Java Virtual Machine instance. At least its current value on your system explains why calling date.getHours() returns UTC time Smiley Happy

Usually, it is configured either by passing -Duser.timezone command line parameter to Java command line, or programmatically. Could you check if your system has this property set in the file /usr/lib/vco/app-server/bin/setenv.sh ?

BTW, when you change the time zone via appliance configuration interface on port 5480, do you also restart vRO service?

View solution in original post

7 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

As far as I know, there are no changes in the code related to timezones.

Could you check what is the time zone of your appliance? Open the URL https://{vroaddress}:5480 in a browser, then go to System > Time Zone tab.

Reply
0 Kudos
Diego_Bejar
Contributor
Contributor
Jump to solution

Hi Ilian Iliev,

The time is correct in the appliance and in the interface too, the problem occurs only when I try to use the method date.getHours(). It's returns the time UTC not the time zone that I had configured in the Orchestrator appliance.

We use the method date.getHours() to get time for some logs because of it we noticed the problem after performed the upgrade of the appliance. No matters what time zone we set the method is returning the same value, the UTC time.

Thanks.

Diego Bejar

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

OK, could you also check the following?

1) What is the value of user.timezone property (it is dumped after vRO service restart in log file /var/log/vco/app-server/server.log)?

2) What is the value returned by a call of date.getTimezoneOffset() method?

Reply
0 Kudos
Diego_Bejar
Contributor
Contributor
Jump to solution

Hi,

This is the value that I found inside the file server.log:

2017-06-27 15:47:19.236+0000 [Thread-24] INFO  {} [O11N] Sysprop: user.timezone = GMT

And when I execute the method date.getTimezoneOffset() the return is 0 (zero).

Do you know what it means?

Thanks again.

Diego Bejar

iiliev
VMware Employee
VMware Employee
Jump to solution

user.timezone is a Java system property which controls the default time zone of a given Java Virtual Machine instance. At least its current value on your system explains why calling date.getHours() returns UTC time Smiley Happy

Usually, it is configured either by passing -Duser.timezone command line parameter to Java command line, or programmatically. Could you check if your system has this property set in the file /usr/lib/vco/app-server/bin/setenv.sh ?

BTW, when you change the time zone via appliance configuration interface on port 5480, do you also restart vRO service?

Diego_Bejar
Contributor
Contributor
Jump to solution

Hello again, Ilian Iliev.

None parameter timezone is found in the setenv.sh file. I will look on the google how to configure it. If you have some tip it will be very helpful.

Answering your other question, yes I restarted vco-server after change the time zone on web interface.

Thanks again.

Diego Bejar

Reply
0 Kudos
Diego_Bejar
Contributor
Contributor
Jump to solution

Hi, Ilian Iliev.

After some tries to solve the problem we found a solution, we put the following line in the beggining of the setenv.sh script: export JAVA_OPTS="-Duser.timezone=GMT-3", so we restart the vco-server service and works! Smiley Happy

We really don't know what happened, but according our logs this problem started after the upgrade of orchestrator version.

Thanks a lot for your help.

Diego Bejar

Reply
0 Kudos