...

...

What about the code fragment show at Roedy's page?
It also mentions things like tz.getOffset() and
tz.getRawOffset().

I am no expert on dealing with calenders and timezones,
beyond knowing there are a lot of pitfalls to this very
complicated area of development.

As an aside.  I am not in '1.5' mode at the moment (heavily
into 1.6), but.. is 1.5.0_11 the very latest 1.5 offered?

Hmm, you shouldn't need to have TZ set. Maybe there is a fault in the system
clock and you have modified your shell environment to counter this. What
version of RedHat are you running? The timezone should be set
by /etc/localtime. The Linux system clock works in UTC, or more correctly the
number of seconds since 00:00 Jan 1 1970 UTC. When you ask for a date/time this
is converted into a local wall clock time based on your timezone setting.

The hardware clock must be set to either UTC or local wall clock time, and the
system configured accordingly. This allows the system clock to be set correctly
when the system boots, which is the only time that Linux normally consults the
hardware clock. Using wall clock time for the hardware clock means you are
responsible for manually altering the hardware clock for DST otherwise the
system clock will be wrong after a re-boot, hence you normally set it to UTC.
You would normally only use wall clock time if the system is dual-boot with
Windows because Windows works in local time (and adjusts the hardware clock for
DST). Linux does its best to correct the broken way that Windows does things,
but it's not infallible.

The system may be converting the "seconds since the epoch" to local time
differently from that of your shell. However I'd expect that Java would use the
same environment as your shell, always supposing you are running Java from the
same shell. What does the command 'date "+%s"' output? This is what the system
clock (not the hardware clock) thinks is the number of seconds since the start
of 1970 (in UTC).  It is also what Java System.currentTimeMillis() should
output (times 1000). If this is wrong it most likely means the hardware (and
therefore system) clock is incorrectly set.

Is your hardware clock set to UTC or CET? Is the system setup accordingly so the
system clock is correctly set from the hardware clock? What's
in /etc/sysconfig/clock?

Perhaps your OS has been configured to ignore daylight saving.

Let's run a more complete test - I want to see TZ offsets and actual
epoch values (which are timezone-agnostic).  I suspect something's
wrong with your timezone definition either in the VM or in the OS.

For the OS (assuming GNU date):

date +%s # seconds since epoch
date +%c # formatted local date
date "+%Z (%z)" # timezone info

for the VM:
import java.util.*;
import java.text.*;
import java.io.*;

public class PrintTime {
   public static void main(String[] args) {
       PrintStream out = System.out;
       long now = System.currentTimeMillis();
       Date nowD = new Date(now);
       TimeZone tz = TimeZone.getDefault();

       out.println("TZ id: " + tz.getID());
       out.println("TZ name: " + tz.getDisplayName());
       out.println("TZ short no-DST name: " + tz.getDisplayName(false,
                   TimeZone.SHORT));
       out.println("TZ short DST name: " + tz.getDisplayName(true,
                   TimeZone.SHORT));
       out.println("TZ offset (mins): " + tz.getOffset(now) / (60 * 1000));
       out.println("TZ uses DST: " + tz.useDaylightTime());
       out.println("TZ in DST now: " + tz.inDaylightTime(nowD));
       out.println("TZ DST savings (mins): " +
               tz.getDSTSavings() / (60 * 1000));
       out.println();

       out.println("seconds since epoch: " + now / 1000);
       out.println("Date toString: " + nowD);
       out.println("SDF: " + new SimpleDateFormat("d MMM yyyy HH:mm:ss z(Z)").
               format(nowD));
   }
}
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>