Date Picker showing one day earlier, even when corrected.

[luizduarte]

Hello everyone, after updating from JIRA 7.4.3 to JIRA 7.13.11(in preparation for 8.5), our Date Picker fields started to behave oddly, they always show one day earlier than the date we input there.

The Date Time Picker is working properly though. A few weeks back we had to apply this correction due to outdated timezone settings. After the update we had to apply it again.

Things I tried.

-(re)updating joda-time for the latest version

-(re) running tzupdater(already has latest version 2019c)

-adding -

-Duser.timezone=America/Sao_Paulo

to the setenv.sh

None of these seemed to work, the date always goes back one day, se if we choose 02/12/2019 it goes to 01/12/2019, inevitably, unless we choose 03/12/2019.

This seemed to happen after our update, and I am at a loss at what to do to fix it. 

[luizduarte · Accepted solution]

I discovered the problem, it appears that the tzupdater doesn't agree to work well with  our JVM - AdoptOpenJDK, at least not with the Vendor being that. Whenever I tried to run it in the JIRA's java, it would crash.

So I had to run the program with the following command line for it to  work.(I created a folder in root folder and placed tzupdater there)

../opt/jira/atlassian-jira-software-7.4.2-standalone/jre/bin/java -Djava.vendor="Oracle Corporation" -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2019c.tar.gz

It worked with no problems and the time zone data was updated correctly.

The key is the  <-Djava.vendor = "Oracle Corporation"> because tzupdater apparently crashes when the Vendor is not Oracle and another I don't recall now. It was the simplest solution I found, there are open source alternatives to tzupdater that are said to work too, but I didn't test them.

[Andy Heinzer]

Hi Luiz,

Sorry to hear about this problem.  I have seen similar problems in regards to when user profile timezones do not align to the system timezone that Jira is currently using.  

Hence most of the time I see this problem it happens because when a user selects a date for due date for example, Jira might only show the date, but it's storing that value in a unix timestamp form that includes date and time.  The time it selects is 00:00 (or midnight).  In turn if another user in Jira has a timezone that is -1 or more hours behind the timezone of the user that selected the date, that date actually appears to be one day behind, only because it is subtracting one hour from the date/time value seen there.   Before you go any further, you might want to check to make sure that the Jira System timezone is the same as the user profile timezones that are making these changes.   

In the case of this timezone change, that could be explaining why you are seeing this, even if all your users are in the same timezone as the Jira system timezone.  Since Brazil changed to stop using daylight savings this year it seems likely that something within your Jira install is still using the old format that believes daylight savings is in affect.  

Looking at the steps in https://confluence.atlassian.com/jirakb/adjusting-daylight-saving-time-brazil-2019-979408558.html I think I can see a potential problem here.  Step #3 says to do this:

Download tzupdater.jar and run the command (don't forget to run the command below from the same Java path being used by Jira):

1. sudo java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2019c.tar.gz

However it is possible that this command could be updating the incorrect java on your system.  It's possible to have more than one installation of Java on your host operating system.  If that happens then we need to be more explicit about which java is being updated here.

You can try to test if this is the case with two different commands:

which java

and

echo $JAVA_HOME

I'd expect these two to be identical values in order for that previous command to work correctly.  If you have different values, try changing the command prompt into the $JAVA_HOME value first, and then instead run

sudo ./java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2019c.tar.gz

The addition of the ./ from within that directory should help to insure that we are updating the Java JRE/JDK that Jira is using when it starts up, and not the other Java on the system. 

If the Java Home variable is not yet set on this system, I would recommend trying to follow the steps in https://confluence.atlassian.com/adminjiraserver/installing-java-938846828.html to do so first, then try to follow these steps and restart Jira once more.

Try this and let me know the results.

Andy

[luizduarte]

Hello Andy, I have applied this solution but it still doesn't work, the Date Time picker issue has been solved but not the Time Zone one(it still shows as -0200).

I have already susbtituted the joda and run tzupdater from many locations, it always says it already has the correct version (2019c)

[Andy Heinzer]

Hi @luizduarte

If you happen to be in Brazil, I would recommend using the KB Adjusting daylight saving time - Brazil, 2019.  Since Brazil stopped using daylight savings in 2019, this KB explains some steps you can take to correct this.

However I have concerns over step 3a in that KB.  You might need to determine if perhaps your system has more than one java version installed.  For a linux/unix system, try using

which java

to see which is expected to be run from a command line.  It might also help to try to run

echo $JAVA_HOME

to see if that variable is set.  If you happen to be on Windows then try

echo %JAVA_HOME%

If the JAVA HOME variable is not set, or the JAVA HOME is different than the results in the 'which java' command, then Jira might be defaulting to a different java version than the one being called via the command line.   I would recommend the guide Installing Java.  Following those steps will help to make sure that when you follow the first KB that your steps will be applied to the Java version that Jira is calling when it starts up.

Please let me know the results.

Andy

[luizduarte]

Hi Andy, I discovered the problem, it appears that the tzupdater doesn't agree to work well with  our JVM - AdoptOpenJDK, at least not with the Vendor being that. Whenever I tried to run it in the JIRA's java, it would crash.

So I had to run the program with the following command line for it to  work.(I created a folder in root folder and placed tzupdater there)

../opt/jira/atlassian-jira-software-7.4.2-standalone/jre/bin/java -Djava.vendor="Oracle Corporation" -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2019c.tar.gz

It worked with no problems and the time zone data was updated correctly.

The key is the  <-Djava.vendor = "Oracle Corporation"> because tzupdater apparently crashes when the Vendor is not Oracle and another I don't recall now. It was the simplest solution I found, there are open source alternatives to tzupdater that are said to work too, but I didn't test them.

[Andy Heinzer]

Thank you for posting your solution here @luizduarte !  It might help others if you post your solution as a separate Answer here (instead of a reply), that way we can accept your answer to mark this as resolved.  Feel free to duplicate your answer there and accept your own answer.

This helps other users that might search our site with similar problems to more easily find your solution.

Thanks again,

Andy

[Tim Nixon]

@Andy HeinzerThe same happens even when viewing the data in Confluence with the timezone set to -5 hours.

Question: is there a way to fix this so it works across timezones?

Perhaps a better question: is there an "absolute date picker" type that if the user picks a date will show as the same no matter the viewers timezone?

Thanks

Tim Nixon