Bug 489586

Summary: Java reads and interprets /etc/sysconfig/clock
Product: [Fedora] Fedora Reporter: Kartik Subbarao <subbarao>
Component: java-1.6.0-openjdkAssignee: Lillian Angel <langel>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: ahughes, dbhole, jhowell, langel, lkundrak, mark, nphilipp, subbarao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.6.0.0-18.b16.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-29 10:10:54 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Kartik Subbarao 2009-03-10 15:32:17 EDT
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:
Comment 1 Nils Philippsen 2009-03-11 05:23:25 EDT
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.
Comment 2 Nils Philippsen 2009-03-11 05:27:32 EDT
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.
Comment 3 Kartik Subbarao 2009-03-11 09:54:45 EDT
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.
Comment 4 Lillian Angel 2009-03-11 10:12:12 EDT
thanks for this. I am looking into it for OpenJDK
Comment 5 Lillian Angel 2009-03-11 11:28:20 EDT
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?
Comment 6 Nils Philippsen 2009-03-11 11:58:39 EDT
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
Comment 7 Lillian Angel 2009-03-11 13:19:42 EDT
/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
Comment 8 Nils Philippsen 2009-03-11 15:08:25 EDT
(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"
Comment 9 Lillian Angel 2009-03-11 15:37:22 EDT
ok, reproducable with both openjdk and jdk 1.6


thanks
Comment 10 Ioana Ivan 2009-05-15 14:43:40 EDT
*** Bug 490015 has been marked as a duplicate of this bug. ***
Comment 11 Fedora Update System 2009-05-30 10:15:44 EDT
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
Comment 12 Fedora Update System 2009-05-30 10:16:45 EDT
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
Comment 13 Fedora Update System 2009-06-02 10:22:28 EDT
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.
Comment 14 Fedora Update System 2009-06-02 10:30:06 EDT
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.
Comment 15 Andrew John Hughes 2009-12-10 12:56:05 EST
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.
Comment 16 Andrew John Hughes 2009-12-10 15:43:21 EST
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

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