Home    HRIS    Oracle Application Server Timezone Changes - No time like the present

Oracle Application Server Timezone Changes – No time like the present

By / November 24, 2009 / / 0 Comments

Have you ever had trouble with daylight savings? No, I’m not talking about sleeping in and being an hour late for work.

Have you ever had your system show the wrong time, scheduled jobs in Alesco or Oracle not run when they’re meant to, or seen conflicting reports of what the current time is in different applications on the one system?

Well, I did recently while administering one of our client’s Alesco environments. The trace outputs for their Alesco reports were showing conflicting runtimes. Surprise, surprise there was an hour difference, and daylight savings was to blame.

Off the top of my head, there were only two places the times could be incorrect:

  • on the database, and
  • on the application server

So, I logged in and checked the database time. All good on that front.
Next, I logged into the application server and checked the system time. That was correct as well.

It seemed that my assumption was incorrect, there was a third place the time could be incorrect, in the Oracle Application Server software. A quick visit to the Oracle Application Server Control Console confirmed this. It turns out the Oracle Application Server software doesn’t use the underlying system’s timezone settings.

Metalink, the Oracle forums and Google were the next ports of call. After a lot of digging (the majority of timezone information I came across dealt with Oracle Databases, not Oracle Application Servers), I discovered that the problem was not specifically with Oracle. Both the Oracle Application Server Control Console and the Oracle Reports Server are Java apps, and it was the Java Runtimes they were using that were causing the timezone issue.

Java (along with Unix/Linux) measures time in milliseconds from January 1st 1970. Once this number has been converted into a human readable time, the timezone adjustments are applied. In Unix/Linux, these timezone settings can be found under /usr/share/zoneinfo (or /usr/share/lib/zoneinfo on some systems). However Java won’t use this system timezone database, it uses it’s own.

Inside your Oracle home, there are a number of java executables. Executing java -version told me I was on 1.4.2_12. A quick comparison with the Java Timezone Data Versions showed this release did not include the Australian 2008 timezone changes. Luckily Sun provides the Timezone Updater Tool to bring us up to speed.

Once you’ve downloaded and unzipped the tool, you can update a single JRE/JDK with the following command:

> java -jar tupdater.jar -U -v

This assumes the java executable is in the home you want to update (type which java to check)

As I said, there’s multiple JRE/JDK homes in the Oracle Application Server homes, so why not update them all at the one time:

> /usr/bin/find DIRPATH -fstype nfs -prune -o -fstype autofs -prune 
-o -name java -print -exec {} -jar /ABSOLUTEPATH/tzupdater.jar -u \;

Then it was just a matter of bouncing the Oracle processes again.

Ta-da, the times are now correct.

I did receive a number of warnings when updating the timezone. It turns out they were Solaris specific and could be ignored, eg:

I get the following message after running the TZ Updater Tool v1.1.0 on Solaris, what does it mean?

/jre/bin/java not directly found in contents file, no package resolution performed.
(May not be in PKG form, not an absolute path, or is a symlink.)

This message indicates that the JDK/JRE software just updated was not part of a Solaris package. No step was necessary to update the OS with the fact that files under package management have changed, that is, jre/lib/zi directory contents. The update of the timezone data has been successful in this case.