This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi All, I have one problem related to java Timezone. I am using Java 1.5.0_11. TimeZone.getDefault().getID() is printing "GMT+05:30" in Windows Server 2003 operating system and if I use the same piece of code in Windows XP then its printing "Asia/Calcutta".
One more thing in Windows Server 2003 machine, if I am using Java 1.4 then the same code is printing "Asia/Calcutta". I am doing some processing depending on the timezone ID returned by this API and since they are the different strings, rest of my program is giving wrong results.
In Windows Server 2003 machine also I am expecting it should return "Asia/Calcutta" while using Java 1.5.0_11. Let me know what is the possible solution. For different operating system is should return the same string. Please help me I am running around this problem for more than one week
Originally posted by Paul Sturrock: Its not the OS that provides the TimeZone string, that's all the JRE. The same JRE running on two different OS's configured to use the same timezone will return the same value.
Sounds like your JVMs are running in different timezones. Try explicitly stating the time when you start the JVM (done via the user.timezone property if the JVM is Hotspot).
Both the JREs are same and running on the same timezone i.e Indian Standard time. According to me, the timezone ids returning are different because Java may be having different id for different Windows Server and Windows XP but that is wrong. "GMT+05:30" and "Asia/Calcutta" both represents the timezone of India but why on differnt operating systems its not returning the same string
Both the JREs are same and running on the same timezone i.e Indian Standard time
What have you done to guarentee this? Trusting that it will be picked up from the OS is not enough. Dump the system properties to a file and check.
Java may be having different id for different Windows Server and Windows XP
Hmm. This should only happen if they are actually running different JVMs. Have a look in your JRE under lib\zi - this is where all the locale-specific data files are kept and where Java gets the value it will return. You could try dumping TimeZone.getAvailableIDs() to you logs, see if the IDs you want exist in both cases?
Joined: Oct 11, 2007
I have double checked the system properties and both OS are printing the same JRE. Still I am seeing the problem. One interesting thing is if I use TimeZone.getAvailableIDs()in Windows Server 2003 machine then I am not finding "GMT+05:30" in available ids. In the ids returned its showing "Asia/Calcutta". I dont think I am doing any wrong thing or using any wrong configuration. Any thoughts???
Lets change tack: what are you trying to do with this value?
Joined: Oct 11, 2007
ok. the thing is I am having a TimezoneMapping.properties file which contains a index (number) to timezone id mappings. For ex - 1=ACT 2=AET 3=Africa/Abidjan 4=Africa/Accra 5=Africa/Addis_Ababa ... 229=Asia/Calcutta ...
So in my code I am trying to find out the default timezone of the server where my code is running. I am using TimeZone.getDefault().getID() to get the server's default timezone id and then comparing the timezone id with the above properties file to get the index. If it matches any id then I will get the key (numeric) and store in our database. Later I use that key to get the timezone ID. So basically I am indexing timezone ids in a property file and storing that index in the database. Then getting the timezone id by using the above api, I am trying to get that index by comparing default timezone id and the one which is present in my property file... So the id returned by java api is "GMT+05:30" and the value in my property file is "Asia/Calcutta". Since they are not matching, I am getting the wrong results..... Any help??? [ October 12, 2007: Message edited by: Sachin Garg ]
Why not map more than one value to a key? That fixes your problem, without having to trawl through the JVM config to find out why the timezone id is as it is. Even the JVM has to do this - if you look under JRE\lib\zi there is a file called ZoneInfoMappings that maps the old, discontinued three letter timezone values (PST, UTC etc. ) with the newer labels.