Develop Reference

Why we need to update time zone information of jdk/jre?

I know that is required because of changes that occurs after the release of the jdk/jre, but why don't get those informations from the server?
As "from the server" i mean from OS. The question is: "Why doesn't Java use the time zone system from the operating system instead of having its own copy of the time zone database"?

Here is my rough understanding. I believe it should at least give you the main reasons.
When Java was designed in the 1990s, a main design goal was that your Java program should be write once run anywhere, popularly abbreviated WORA. At that time cross-platform programs were not that commonplace. Porting your Windows program to a Mac or vice versa required quite some effort. Sun, the company that developed Java, was selling an operating system called Solaris, a Unix variant that not that many wanted to port to or from.
Different operating systems have different time zone data: different structure, different names for the time zones, different amounts of detail. Windows, for example, hasn’t got the full history of offsets for all time zones. What Mac and Unix had in the 1990s I don’t know. There were many Unix variants back then, and I am not even sure whether they all had built-in time zone information.
So relying on the operating system would mean that a program doing for example TimeZone.getTimeZone("America/Sao_Paulo") (using the time zone class from back then, now long outdated) would not be portable because on another operating system the time zone would not be called that. The write once run anywhere idea would be seriously harmed.
I suppose that this was the main reason for choosing that Java needed to have its own built-in time zone database, the same on all operating systems. I also believe that the choice of the Olson database, also known as tzdata, the zoneinfo database or IANA time zone database, was rather obvious. And from this choice came also the need for being able to update the timezone data, since the database is constantly evolving, especially since politicians around the globe are constantly (and eagerly, it would appear) deciding on new time zone rules.
Links for comparison:
List of tz database time zones
Windows Default Time Zones
Please notice that the former uses time zone IDs like America/Sao_Paulo, that is the region/city format, while the latter instead uses names like E. South America Standard Time.

Fetching JVM timezone on Linux Box

Is it possible to get the TIMEZONE set in JVM using a command in Linux? I am trying to fetch this information from a production box where I wouldn't able to deploy any code to check.

JVM makes some statistics about the app available via JMX, and some are available by default, so it's rather likely you will be able to retrieve them from your app, too. You can use jconsole tool to connect to a Java app and read those values. I don't see the clock time being one of them, but you can check the application's startup time, and the uptime. Adding one to the other gives you the current time as the app sees it. You can find both values in jconsole in the "MBeans" tab: in the tree on the left select: java.lang / Runtime / Attributes - they will be called "Uptime" and "StartTime". Uptime is in milliseconds and StartTime is in milliseconds since January 1st, 1970.
PS: If the above doesn't work, you can try to retrieve the time indirectly. The time returned by System.currentTimeMillis() is based on the machine's clock, so it should be the same as returned by any other program that queries the clock, e.g. the command-line date command. One possible deviation would be the possibility of the java application using a different time zone, e.g. due to environment variables set differently than for your command-line program.

no. this is not possible. you cannot get the time set in JVM using a command in linux. for further information run "java" command in command prompt or console and you will see which commands JVM can receive directly

JBoss timezone is getting changed automatically

We are facing one funny and interesting issue with our JBoss app server.
The problem is we are running the JBoss in Linux server which is running in different time zone (say, America/Chicago).
Also with the same timezone we are starting the JBoss server by setting -Duser.timezone=xxx JVM parameter.
Although it's running fine as per the configuration for 5 or 6 days.
After that the JBoss app server's time zone is getting changed automatically to some other time zone say (Asia/Kolkata). For this we have analyzed lot but we are not able to figure it out and as of now restart of JBoss is required to get things normal.
So I wanted to know, is there any way to restrict this or to reset to old timezone without restarting JBoss?

Do you want to change the timezone of the server?
You can do it with tzselect command. I had a similar issue recently and I had documented it. You can refer if you want. its here

Time zone is not working properly in windows server

If run this code in windows machine, its works properly:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
System.out.println(sdf.format(new Date()));
It shows date & time same as clock, but the same code if I run on Windows Server it's showing -2hrs of clock time.
I tried by the setting the timezone as,
TimeZone timeZone = TimeZone.getTimeZone("Europe/Vienna");
sdf.setTimeZone(timeZone);
Then, it shows same as clock time.
My doubt is why is it not taking the clock time zone by default in Windows Server.

It should always take the time zone of the running machine but in some case it fails as reported here and here. If you are sure that your server time zone is correct but Java uses a different one, you can force a default time zone of your choice from the command line:
-Duser.timezone="YOUR_TIME_ZONE_HERE"
or by code. You can also try with the Timezone Updater Tool by Oracle.
To see the time zone used by Java:
System.out.println(TimeZone.getDefault());

Time zone settings have no effect on a time value as the computer sees it. See my answer here for details. So long as the system time is set properly (regardless of time zone) and you don't need to display the time as text or parse the time from text, java will have no trouble and its calculations will be correct. If you do need to display/parse a time value, setting the default time zone is safe and it won't effect how times are stored, except of course Java will use that time zone to parse text representations of time that don't explicitly specify the time zone (like if you used the SimpleDateFormat in your example to parse, since the format string doesn't include the time zone).
As for why Java has this problem on your server box but not your desktop box, what version of Windows Server is it, and what version Java is running on the server? My guess is that the JVM can't unambiguously identify the OS version and therefore can't know for sure how to get the local time zone, so uses UTC as a fallback. Try updating your java version to the latest.
Another possibly is that the time zone on the server is set on a per-user basis. Verify that the time zone for the user/process that is running the app on the server is set properly.

There is a bug open at Oracle about that problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044727. Basically it's because Java pulls the timezone out of the registry. And Windows saves it in HKLocalMachine, which is not the Client time but the time of the machine.

I had this issue after upgrading from 2003 server to 2008 server. Java keeps using GMT timezone instead of Windows Timezone setting. The solution is simple, go to Windows control panel and change to a different Timezone(whatever timezone is fine), then change it back. Took me hours to figure it out but it worked as charm.
My thought: the change triggerred something in Java, which correct the issue.

Java is using 100% of cpu on linux

On my linux server, any java program (even the "Hello world") uses 100% of cpu and is very very slow. Id does not depend on the java version, I have tried different versions of openjdk and sun jdk, both behave the same. How could I fix that?

I have found the solution in this article http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/
There is a great chance, this is caused by the "leap second kernel bug". Firstly, check for the following in the dmesg
[10703552.860274] Clock: inserting leap second 23:59:60 UTC
To fix it, firstly stop the ntp client. On debian-like systems
/etc/init.d/ntp stop
Store the current time
date -s now
And test the java. If everything is working correctly, try to restart ntp service
/etc/init.d/ntp start
And test it again.