Bug 489586

No program (except system-config-date itself) should ever access the /etc/sysconfig/clock file.

The real time zone of the system (unless you set a TZ environment variable overriding it) is defined by the contents of /etc/localtime which is copied over from a file beneath /usr/share/zoneinfo by system-config-date. E.g. I set the time zone to New York in system-config-date, then the /etc/sysconfig/clock is (again, the missing underscore shouldn't do any harm here, as system-config-date interprets the file correctly and nothing else should read it):

# The ZONE parameter is only evaluated by system-config-date.
# The time zone of the system is defined by the contents of /etc/localtime.
ZONE="America/New York"

and the relevant zone files' checksums are:

nils@wombat:~> md5sum /etc/localtime /usr/share/zoneinfo/America/New_York 
e4ca381035a34b7a852184cc0dd89baa  /etc/localtime
e4ca381035a34b7a852184cc0dd89baa  /usr/share/zoneinfo/America/New_York

i.e. the system time is set correctly to that of New York.

I've straced what Java did:

[pid 27209] open("/etc/sysconfig/clock", O_RDONLY) = 6

Lo and behold, it reads /etc/sysconfig/clock which it shouldn't do because s-c-date could just write the file in Klingon next time if I feel like it ;-).

I'll change the component to java-1.6.0-openjdk so it can be fixed in OpenJDK. Somebody (not me) should ping Sun (and IBM?) about it so they can fix it in their respective proprietary versions.

BTW: I'll change the warning boilerplate to this to make it more clear:

# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.

Thanks for the quick response! It looks like the problem (both in OpenJDK and Sun's JDK) is in the getPlatformTimeZoneID() function in jdk/src/solaris/native/java/util/TimeZone_md.c. This function first checks /etc/sysconfig/clock before checking /etc/localtime. The comments in that section of code refer to some likely obsolete understanding of the purpose of the /etc/sysconfig/clock file:

    /*
     * First, try the ZONE entry in /etc/sysconfig/clock. However, the
     * ZONE entry is not set up after initial Red Hat Linux
     * installation. In case that /etc/localtime is set up without
     * using timeconfig, there might be inconsistency between
     * /etc/localtime and the ZONE entry. The inconsistency between
     * timeconfig and linuxconf is reported as a bug in the Red Hat
     * web page as of May 1, 2000.
     */

I looked around and found that this problem has been open for a while at Sun:

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

The Ubuntu folks have encountered this too:

https://bugs.launchpad.net/debian/+source/sun-java5/+bug/49068

Hopefully, getting this fixed in OpenJDK will help drive a fix with Sun's JDK as well.

thanks for this. I am looking into it for OpenJDK

I can't reproduce this with the version of OpenJDK in rawhide:

$ java Test
Default TZ=sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
Now=Wed Mar 11 11:26:46 EDT 2009

Is that correct?

Do you have /etc/sysconfig/clock? What are its contents?

This is what I get with /etc/localtime being Europe/Berlin and ZONE being "Something with a lot of spaces", "America/New_York" and "America/New York" (in that order):

nils@wombat:~/test/java/tz> java -version
java version "1.6.0_0"
IcedTea6 1.4 (fedora-9.b14.fc10-x86_64) Runtime Environment (build 1.6.0_0-b14)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)
nils@wombat:~/test/java/tz> java Test
Default TZ=sun.util.calendar.ZoneInfo[id="GMT+01:00",offset=3600000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Now=Wed Mar 11 16:56:28 GMT+01:00 2009
nils@wombat:~/test/java/tz> java Test
Default TZ=sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
Now=Wed Mar 11 11:56:56 EDT 2009
nils@wombat:~/test/java/tz> java Test
Default TZ=sun.util.calendar.ZoneInfo[id="GMT+01:00",offset=3600000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Now=Wed Mar 11 16:57:21 GMT+01:00 2009

/etc/sysconfig/clock:

# The ZONE parameter is only evaluated by system-config-date.
# The time zone of the system is defined by the contents of /etc/localtime.
ZONE="America/New_York"
UTC=true
ARC=false


from rawhide:
$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (fedora-13.b14.fc11-i386)
OpenJDK Server VM (build 14.0-b08, mixed mode)


$ java Test
Default TZ=sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
Now=Wed Mar 11 13:18:10 EDT 2009

(In reply to comment #7)
> /etc/sysconfig/clock:
> 
> # The ZONE parameter is only evaluated by system-config-date.
> # The time zone of the system is defined by the contents of /etc/localtime.
> ZONE="America/New_York"
> UTC=true
> ARC=false

That looks mighty old, s-c-date hasn't written UTC/ARC lines for quite a while. What OS version do you have and when have you last used s-c-date or run firstboot?

Replace your /etc/sysconfig/clock with something like this for testing:

# The ZONE parameter is only evaluated by system-config-date.
# The time zone of the system is defined by the contents of /etc/localtime.
ZONE="America/New York"

ok, reproducable with both openjdk and jdk 1.6


thanks

*** Bug 490015 has been marked as a duplicate of this bug. ***

java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-18.b16.fc10

java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-22.b16.fc11

java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Sun have a different fix for this now in OpenJDK:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719

It removes the parsing of /etc/timezone/clock and adds parsing of Debian's /etc/localtime, and so should also fix this bug by causing /etc/localtime to be used on RH systems.

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

The above fix is also in the proprietary Sun JDK 6u18 b02.