Red Hat Bugzilla – Bug 489586
Java reads and interprets /etc/sysconfig/clock
Last modified: 2009-12-10 15:43:21 EST
Description of problem: The default ZONE parameter set by system-config-date in /etc/sysconfig/clock is misspecified as America/New York instead of America/New_York (i.e, with a space as opposed to an underscore). This causes programs like Java which look up the timezone file based on this setting to fail. The problem is described in detail on this web page by Brian Zimian: http://www.brianziman.com/r/post/blog-200806201735 Version-Release number of selected component (if applicable): 1.9.36 How reproducible: Always Steps to Reproduce: Here is sample Java code that illustrates the problem: import java.util.*; public class Test { public static void main(String args[]) throws Exception { System.err.println("Default TZ="+TimeZone.getDefault()); System.err.println("Now="+new Date()); } } Actual results: Default TZ=sun.util.calendar.ZoneInfo[id="GMT-05:00",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null] Now=Tue Mar 10 14:30:10 GMT-05:00 2009 Expected results: 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=Tue Mar 10 15:30:10 EDT 2009 Additional info:
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.