Hello,
I am currently facing the timezone problem Bug ID: JDK-7044727 (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session with Windows Server 2008 R2
In short, starting a JVM in a Windows terminal session will set the timzone of the JVM to the servers timezone instead of the clients timezone.
This problem is caused by the way the JVM tries to get the timezone from the Windows system. From what I have read, the client timezone in a terminal session can only be recovered correctly by using Windows API. The call to get the correct tiemzone lies in the GetDynamicTimeZoneInformation function http://msdn.microsoft.com/en-us/library/windows/desktop/ms724318%28v=vs.85%29.aspx. In Windows Server 2003 it was called GetTimeZoneInformation.
So at the moment it looks like I can't use Oracles JVM in a terminal server session if I run the clients in different locations around the world and still use java.util.Date without additional work.
So I am pondering about different ideas to get a workaround for that problem. And I can't decide for a good solution
a) Using a powershell script to read the information from the client at startup and place it in a user variable. Then starting the JVM with the parameter -Duser.timezone=GMT+%TIMEZONE%. I'd adapt that script from here: Setting the Time Zone using Windows PowerShell - The Deployment Guys - Site Home - TechNet Blogs
b) Starting the JVM and using JNI/Windows API in my application (namely an Eclipse Rich Client) to get those timezone settings to set the timezone correctly after the JVM has already started usingTimeZone.setDefault(timeZone)
c) Let my users chose their own timezone in my application and set it with usingTimeZone.setDefault(timeZone)
d) Don't change the JVMs timezone, but use a custom reimplementation of Date/Callendar.
e) Call the Windows API via JNI wherever I need it
At the moment I would prefer (*) a), because I start the JVM with the correct timezone and don't have to fiddle around. But powershell scripting is not a sweet thing to do and it means that I have to take care of a component outside my JVM/application. As I have read setting the TimeZone.setDefault(timeZone) JVM variable like b) and c) can fail if the user does not have the rights to access the JVMs parameter. Weired things can happen like timezone settings that are only done in the current thread. In addition c) would mean that the user would have to know his timezone, which is a hard task for most users . d) and e) would mean lots of refactoring and code changes, since the application is handling timestamped tickets.
So none of those workarounds is a top choice for me at the moment.
Does anyone have an idea or opinion on this problem? As I said I am just pondering about it and maybe someone in here can bring up a good point that lets me think in a new way.
Thanks
Benjamin
(*) ... Oracle to fix that.. but that is an unlikely case, since they made it a Prio 4 bug, so...