JDK-7044727 : (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2008
  • CPU: x86
  • Submitted: 2011-05-13
  • Updated: 2016-06-13
  • Resolved: 2015-04-17
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.
JDK 7 JDK 8 JDK 9
7u91Fixed 8u60Fixed 9 b61Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows Server 2008 R2 Standard with SP 1
Microsoft Windows [Version 6.1.7601]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Windows Server time zone is 'America/New_York'
Client time zone is 'Europe/Helsinki'

A DESCRIPTION OF THE PROBLEM :
TimeZone.getDefault() call returns server time zone ('America/New_York') instead of client's ('Europe/Helsinki') at Windows 2008 in Time Zone redirection mode for terminal sessions. This mode mean that any Remote Terminal session have own, client time zone.

Here is explanation of "Allow time zone redirection" mode in Windows
http://technet.microsoft.com/en-us/library/cc725887%28WS.10%29.aspx

I've reviewed JDK's native sources and found that problem reason is in TimeZone_md.c file at the method getWinTimeZone(...) Here Java uses registry path "System\\CurrentControlSet\\Control\\TimeZoneInformation" and string attr "TimeZoneKeyName" there for determining system TZ in modern Windows systems. But it seems this value always has server time zone even in "Allow time zone redirection" mode.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- setup "Allow time zone redirection" in Windows 2008 srv
- logon into Windows 2008 srv through Remote Desktop from different time zone
- call from console
jrunscript.exe -e "java.lang.System.out.println(java.util.TimeZone.getDefault());"

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
- see in the console server time zone while in Windows Contol Panel (or throught call tzutil /g) you'll see client's time zone
ACTUAL -
C:\tmp>C:\tools\Java\jdk1.6.0_u23\bin\jrunscript.exe -e "java.lang.System.out.println(java.util.TimeZone.getDefault());"
sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_Y
ork,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,en
dMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]

C:\tmp>tzutil /g
FLE Standard Time

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use -D param 'user.timezone' for mandatory time zone set for JVM. Unfortunately, our clients may logon into Windows server from different time zones and this workaround isn't an option for us.

Comments
A regression test requires Windows terminal session setup. So, no regression tests are provided with the fix.
07-04-2015