United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7092679 (tz) Java getting wrong timezone/DST info on Solaris 11
JDK-7092679 : (tz) Java getting wrong timezone/DST info on Solaris 11

Details
Type:
Bug
Submit Date:
2011-09-20
Status:
Resolved
Updated Date:
2012-03-21
Project Name:
JDK
Resolved Date:
2011-10-18
Component:
core-libs
OS:
solaris_nevada
Sub-Component:
java.util:i18n
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
While trying to debug a timing issue in other code, it was noticed that
timestamps in Cacao log files were incorrect. Investigation by a Cacao
engineer highlighted a problem with JVM timezone handling on S11.

On a system running s10s_u10wos_10, and Java version:
---
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)
---
and in timezone MET the simple program given in the comments works as expected:
$ date ; java ShowDate
Tuesday, September 20, 2011 10:42:01 AM MEST
Timezone is Middle Europe Time
Date is Tue Sep 20 10:42:01 MEST 2011

however trying the same program on a system with Solaris 11 snv_173 and
Java version:
--
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
--
the program shows that the system time is correct, but the time seen by
Java is one hour out:
$ date ; java ShowDate
Tue Sep 20 01:41:24 PDT 2011
Timezone is GMT-08:00
Date is Tue Sep 20 00:41:24 GMT-08:00 2011

For the second system the timezone is set to US/Pacific, but uses the
post-PSARC/2011/057 mechanism. File /etc/default/init contains the line:
TZ=localtime
and the timezone file links are:
/usr/share/lib/zoneinfo/localtime -> ../../../../etc/localtime
/etc/localtime -> ../usr/share/lib/zoneinfo/US/Pacific

Setting the TZ variable to be US/Pacific directly in my environment gives
the correct behaviour:

$ setenv TZ US/Pacific
$ date ; java ShowDate
Tue Sep 20 01:45:35 PDT 2011
Timezone is Pacific Standard Time
Date is Tue Sep 20 01:45:36 PDT 2011

It seems that the JVM isn't handling the S11 configuration method correctly.

                                    

Comments
WORK AROUND

Set TZ to a zoneinfo name, such as US/Pacific.
                                     
2011-09-20
EVALUATION

This 3-month old structure on S11 hasn't been supported.
                                     
2011-09-20
EVALUATION

I have to differ with the evaluation of this being moved to a P3.

This evaluation means that all Solaris 11 systems, out of the box, will have JVMs which report incorrect time/date information.

If my understanding is correct, user accounts as well as root accounts will by default now have the 'localtime' TZ setting, and so all JVMs will by default have this bug active.

This seems very serious to me, not a P3.

I would argue that it might even be considered as a stopper for Solaris 11 FCS if it's not already too late, but if not it should be fixed ASAP afterwards.

Thanks,

 [ Nick ]
                                     
2011-09-20
EVALUATION

A must agree with Nick on this.

For a standard function within the core Java VM to return incorrect time
info to an application does not seem like a matter for an RFE, nor a P3.
This could potentially be considered to be a security issue, since any log
and audit information generated by such programs will be incorrect.

As to the "easy workaround", if you're referring to setting the TZ variable
in the environment, that may be OK for a simple user program but in this
case it is a Solaris service started by SMF that is impacted. Do we really
consider it an acceptable workaround for users to edit Solaris SMF startup files?

Please re-evaluate this.

Thanks
                                     
2011-09-22
EVALUATION

The TZ value of both the enviroment variable and file /etc/default/init is no longer usable for identifying the platform time zone due to the incompatible change. Decided to use the same method as Linux to determine what /usr/share/lib/zoneinfo/localtime is rather than depending on the undocumented symbolic link structure.
                                     
2011-09-26



Hardware and Software, Engineered to Work Together