Java ignoring Daylight Savings Time

[lemmuh-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org (David Hummel)]

On Fri, May 8, 2009 at 3:52 PM,  <david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org> wrote:
> I posted this problem in Sun's support forum and didn't get an answer
> there, but I finally found the solution. ?But the solution is so bat-s**t
> crazy, I just had to post it here.
>
> I've used Calendar, Date, and System.currentTimeMillis(). ?It all converts
> to one hour earlier than it should. ?If it's now 8:54 EST (12:54 GMT), and
> the time from all of those translate to 7:54am. ?Googling around I
> couldn't see a fix, but I do see clear indications that the problem is a
> time zone one.
>
> Here's the answer, which I found at
> http://www.velocityreviews.com/forums/t679924-p4-diagnose-why-pacific-tz-has-wrong-startstop-dates-for-dst-with-jdk16-on-ubuntu.html
>
> Sun's Java under Linux needs /etc/localtime to be a symbolic link to the
> right timezone file under /usr/share/zoneinfo. Even if /etc/localtime is
> checksum identical to the timezone file, it won't work right, because it
> uses the name of the file being linked to to determine certain
> information. If /etc/localtime is NOT a symbolic link to a timezone file,
> it uses the name of the first timezone file it finds with identical
> contents to /etc/localtime.

Actually your characterization is not quite correct.  This has been a
known issue for quite some time:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Making /etc/localtime a symlink is a deprecated Redhat-ism that may
have other undesirable side effects.

The distribution-independent way to fix this is to set the TZ
environment variable prior to executing the JVM:

export TZ=America/New_York

On Debian and derived distributions, you can do this:

export TZ=$( cat /etc/timezone )

On Redhat and derived distributions, setting TZ is unnecessary if the
ZONE entry in /etc/sysconfig/clock is correct and properly
double-quoted.