-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b61
-
x86
-
windows_2008
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8084797 | emb-9 | Masayoshi Okutsu | P3 | Resolved | Fixed | team |
JDK-8086864 | 8u65 | Masayoshi Okutsu | P3 | Resolved | Fixed | b01 |
JDK-8077922 | 8u60 | Masayoshi Okutsu | P3 | Resolved | Fixed | b14 |
JDK-8138164 | emb-8u65 | Unassigned | P3 | Resolved | Fixed | b01 |
JDK-8079962 | emb-8u60 | Masayoshi Okutsu | P3 | Resolved | Fixed | team |
JDK-8081494 | 7u91 | Aleksej Efimov | P3 | Resolved | Fixed | b01 |
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.
- backported by
-
JDK-8077922 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved
-
JDK-8079962 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved
-
JDK-8081494 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved
-
JDK-8084797 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved
-
JDK-8086864 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved
-
JDK-8138164 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session
- Resolved