JDK-7092679 : (tz) Java getting wrong timezone/DST info on Solaris 11
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_nevada
  • CPU: generic
  • Submitted: 2011-09-20
  • Updated: 2016-09-16
  • Resolved: 2011-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u30Fixed 7u2Fixed 8 b10Fixed
Related Reports
Relates :  
Relates :  
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:
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.

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.

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

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 ]

WORK AROUND Set TZ to a zoneinfo name, such as US/Pacific.

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