2009/12/3 Bill Tims (RSI) <bt...@rsitex.com>:
> Andrew/Masayoshi
>
> 1) I installed openjdk-6-jdk(I only had the jre-lib installed before)
> and reran the following code. This didn't seem to make any difference.
> 2) Andrew's last email references the tzdata-java package.
> After the run with the jdk installed I installed the tzdata-java
> package and now have the /usr/share/javazi/.
> Yet I still get the same results with different tz data AND it
> still uses CST6CDT even after I told it to use America/Chicago. I'm
> guessing that the ZoneInfoMappings file is causing this, the Chicago file
> seems to be a subset of the CST6CDT file.
> When I use zdump to dump the CST6CDT file (it doesn't seem to
> matter which one I use, I get the same results for all of them), the first
> few lines are:
> CST6CDT Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 14:45:52 1901 CST isdst=0
> gmtoff=-21600
> CST6CDT Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 14:45:52 1901 CST isdst=0
> gmtoff=-21600
> CST6CDT Sun Mar 31 07:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 CST isdst=0
> gmtoff=-21600
> CST6CDT Sun Mar 31 08:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 CDT isdst=1
> gmtoff=-18000
> The first instance CDT is in 1918, I don't understand why the offset
> is being used. I am really getting confused here.
>
>
> Bill
>
> public void test2() {
> System.out.println("version="+System.getProperty("java.version"));
> System.out.println("vendor="+System.getProperty("java.vendor"));
>
> System.out.println("java.vm.specification.version="+System.getProperty("java.vm.specification.version"));
>
> System.out.println("java.vm.specification.vendor="+System.getProperty("java.vm.specification.vendor"));
>
> System.out.println("java.vm.version="+System.getProperty("java.vm.version"));
>
> System.out.println("java.vm.vendor="+System.getProperty("java.vm.vendor"));
> Calendar cal = Calendar.getInstance();
> TimeZone tz = TimeZone.getDefault();
> tz.setID("America/Chicago");
> System.out.println("timezone.id="+tz.getID());
> cal.set(1900, Calendar.JANUARY,1,0,0,0);
> System.out.println("January, 1900 timezone
> offset:"+tz.getOffset(GregorianCalendar.AD, 1900,0, 1, 1, 1));
> }
>
> and got:
> version=1.6.0_0
> vendor=Sun Microsystems Inc.
> java.vm.specification.version=1.0
> java.vm.specification.vendor=Sun Microsystems Inc.
> java.vm.version=1.6.0_0-b11
> java.vm.vendor=Sun Microsystems Inc.
> timezone.id=America/Chicago
> January, 1900 timezone offset:-18000000
> ===========================================================================================
> The relevant portion of the strace with the openjdk-6-jdk is:
> 14565 gettimeofday({1259842962, 719472}, NULL) = 0
> 14565 stat64("/usr/share/javazi/ZoneInfoMappings", 0xb735dd4c) = -1 ENOENT
> (No such file or directory)
> 14565 gettimeofday({1259842962, 719759}, NULL) = 0
> 14565 _llseek(3, 48488574, [48488574], SEEK_SET) = 0
> 14565 read(3, "PK\3\4\n\0\0\0\0\0\255\236>:H\250\221\265$\5\0\0$\5\0\0"...,
> 30) = 30
> 14565 _llseek(3, 48488642, [48488642], SEEK_SET) = 0
> 14565 read(3, "\312\376\272\276\0\0\0001\0R\t\0\22\0000\n\0\23\0001\7"...,
> 1316) = 1316
> 14565 gettimeofday({1259842962, 720973}, NULL) = 0
> 14565 gettimeofday({1259842962, 721007}, NULL) = 0
> 14565 gettimeofday({1259842962, 721021}, NULL) = 0
> 14565 gettimeofday({1259842962, 721026}, NULL) = 0
> 14565 gettimeofday({1259842962, 721853}, NULL) = 0
> 14565 gettimeofday({1259842962, 722020}, NULL) = 0
> 14565 gettimeofday({1259842962, 722175}, NULL) = 0
> 14565 gettimeofday({1259842962, 722269}, NULL) = 0
> 14565 gettimeofday({1259842962, 722276}, NULL) = 0
> 14565 gettimeofday({1259842962, 722279}, NULL) = 0
> 14565 gettimeofday({1259842962, 722838}, NULL) = 0
> 14565 access("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", R_OK)
> = 0
> 14565 stat64("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT",
> {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
> 14565 open("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT",
> O_RDONLY|O_LARGEFILE) = 5
> 14565 fstat64(5, {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
> 14565 fcntl64(5, F_GETFD) = 0
> 14565 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
> 14565 read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"...,
> 2288) = 2288
> 14565 close(5) = 0
> ===========================================================================================
> This is strace data generated after the tzdata-java package was installed.
>
> 14662 stat64("/usr/share/javazi/ZoneInfoMappings", {st_mode=S_IFREG|0644,
> st_size=14640, ...}) = 0
> 14662 gettimeofday({1259843375, 580436}, NULL) = 0
> 14662 _llseek(3, 48488574, [48488574], SEEK_SET) = 0
> 14662 read(3, "PK\3\4\n\0\0\0\0\0\255\236>:H\250\221\265$\5\0\0$\5\0\0"...,
> 30) = 30
> 14662 _llseek(3, 48488642, [48488642], SEEK_SET) = 0
> 14662 read(3, "\312\376\272\276\0\0\0001\0R\t\0\22\0000\n\0\23\0001\7"...,
> 1316) = 1316
> 14662 gettimeofday({1259843375, 581372}, NULL) = 0
> 14662 gettimeofday({1259843375, 581552}, NULL) = 0
> 14662 gettimeofday({1259843375, 581750}, NULL) = 0
> 14662 gettimeofday({1259843375, 581937}, NULL) = 0
> 14662 gettimeofday({1259843375, 582143}, NULL) = 0
> 14662 gettimeofday({1259843375, 582338}, NULL) = 0
> 14662 gettimeofday({1259843375, 582509}, NULL) = 0
> 14662 gettimeofday({1259843375, 582682}, NULL) = 0
> 14662 gettimeofday({1259843375, 582865}, NULL) = 0
> 14662 gettimeofday({1259843375, 583036}, NULL) = 0
> 14662 gettimeofday({1259843375, 583206}, NULL) = 0
> 14662 access("/usr/share/javazi/SystemV/CST6CDT", R_OK) = 0
> 14662 stat64("/usr/share/javazi/SystemV/CST6CDT", {st_mode=S_IFREG|0644,
> st_size=2288, ...}) = 0
> 14662 open("/usr/share/javazi/SystemV/CST6CDT", O_RDONLY|O_LARGEFILE) = 5
> 14662 fstat64(5, {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
> 14662 fcntl64(5, F_GETFD) = 0
> 14662 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
> 14662 read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"...,
> 2288) = 2288
> 14662 close(5) = 0
>
>
> Bill Tims
>
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX 78751
> 512-275-0344
>
>
>
>
Interesting that installing the java-tzdata package made no
difference. Using your testcase, I can't replicate the failure here:
With IcedTea6 (using the hs16 vm):
version=1.6.0_0
vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.version=16.0-b10
java.vm.vendor=Sun Microsystems Inc.
timezone.id=America/Chicago
January, 1900 timezone offset:0
With IcedTea7:
version=1.7.0_0-icedtea
vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.version=17.0-b05
java.vm.vendor=Sun Microsystems Inc.
timezone.id=America/Chicago
January, 1900 timezone offset:0
My local timezone is Europe/London. So maybe the timezone data is not
to blame and some system setting is at fault?
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
