From gnu_andrew at member.fsf.org  Wed Dec  2 06:53:51 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 2 Dec 2009 14:53:51 +0000
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <4B149CB6.6000601@sun.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
Message-ID: <17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>

2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
> What is the time zone ID you are using?
>
> Thanks,
> Masayoshi
>
> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>
>> From what I can find, this appears to be the right place to post this, if
>> I'm wrong I would appreciate a pointer to the proper location.
>> ?The database our app has to talk to has January 1,1900 12:00:00 am date
>> in it. ?When I load the value into a open
>> jdk date object (using Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899
>> 23:00:00. ?When I do the same thing on my
>> dev box (Win XP/Sun jre 1.6.0_07) I get January 1, 1900 12:00:00 am. ?I
>> wrote a test program that prints out the
>> Timezone info for 1898-1902 and it appears that the open jdk has a
>> daylight savings time starting on Jan 1, 1900 through
>> Oct 1, 1900 and the sun version doesn't. ?According to Wikipedia, Daylight
>> savings wasn't suggested until 1907.
>> ?I can't find anything on the web that suggests where the timezone info is
>> kept or how complicated it will be to rebuild whatever jar
>> file is required. Can someone point me to the proper source file and
>> suggest how involved building the fix will be?
>> ?Thanks
>> ???Bill
>> ?!
>>
>> Bill Tims
>>
>> Renaissance Systems, Inc.
>>
>>
>>
>

You don't give any details of the OpenJDK version - what does 'java
-version' give on your Ubuntu box?
If this is the system OpenJDK build, then it's an IcedTea build and
thus includes a patch to use the system timezone data which is likely
to be more up-to-date than that bundled with Sun's JDK.
-- 
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

From btims at rsitex.com  Wed Dec  2 10:39:58 2009
From: btims at rsitex.com (Bill Tims (RSI))
Date: Wed, 2 Dec 2009 12:39:58 -0600
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
Message-ID: <AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>

Andrew/Masayoshi

   After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu. The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.  

When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
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
date=Mon Jan 01 00:00:00 CDT 1900
1900/0:-18000000
1900/1:-18000000
1900/2:-18000000
1900/3:-18000000
1900/4:-18000000
1900/5:-18000000
1900/6:-18000000
1900/7:-18000000
1900/8:-18000000
1900/9:-18000000
1900/10:-21600000
1900/11:-21600000

The display is year/month#:offset.  
The same program running under the Sun jdk on windows gives me:
version=1.6.0_07
vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.version=10.0-b23
java.vm.vendor=Sun Microsystems Inc.
timezone.id=America/Chicago
date=Mon Jan 01 00:00:00 CST 1900
1900/0:-21600000
1900/1:-21600000
1900/2:-21600000
1900/3:-21600000
1900/4:-21600000
1900/5:-21600000
1900/6:-21600000
1900/7:-21600000
1900/8:-21600000
1900/9:-21600000
1900/10:-21600000
1900/11:-21600000

Bill

Bill Tims
Renaissance Systems, Inc.
5426 Guadalupe, Suite 100
Austin, TX  78751
512-275-0344
 

-----Original Message-----
From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
Sent: Wednesday, December 02, 2009 8:54 AM
To: Masayoshi Okutsu
Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> Open Jdk Timezone bug?

2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
> What is the time zone ID you are using?
>
> Thanks,
> Masayoshi
>
> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>
>> From what I can find, this appears to be the right place to post 
>> this, if I'm wrong I would appreciate a pointer to the proper location.
>> ?The database our app has to talk to has January 1,1900 12:00:00 am 
>> date in it. ?When I load the value into a open jdk date object (using 
>> Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00. ?When I 
>> do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I get 
>> January 1, 1900 12:00:00 am. ?I wrote a test program that prints out 
>> the Timezone info for 1898-1902 and it appears that the open jdk has 
>> a daylight savings time starting on Jan 1, 1900 through Oct 1, 1900 
>> and the sun version doesn't. ?According to Wikipedia, Daylight 
>> savings wasn't suggested until 1907.
>> ?I can't find anything on the web that suggests where the timezone 
>> info is kept or how complicated it will be to rebuild whatever jar 
>> file is required. Can someone point me to the proper source file and 
>> suggest how involved building the fix will be?
>> ?Thanks
>> ???Bill
>> ?!
>>
>> Bill Tims
>>
>> Renaissance Systems, Inc.
>>
>>
>>
>

You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
--
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

From gnu_andrew at member.fsf.org  Wed Dec  2 12:09:38 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 2 Dec 2009 20:09:38 +0000
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
Message-ID: <17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>

2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
> Andrew/Masayoshi
>
> ? After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu.

Ok, newer versions will also include the IcedTea version in java -version,

$ /home/andrew/build/icedtea6/bin/java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.7pre-r1b34da20e2d1) (build 1.6.0_0-b17)
OpenJDK 64-Bit Server VM (build 16.0-b10, mixed mode)

but I think those that use OpenJDK6 b11 are too old to do so.

> The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.

The latest is b17, the number Masayoshi quotes sounds like a version
of the proprietary JDK6 (as you are using on Windows, 6u7 in that
case) rather than an OpenJDK6 version.
It would be nice if such responses were posted to the public list...

>
> When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
> 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
> date=Mon Jan 01 00:00:00 CDT 1900
> 1900/0:-18000000
> 1900/1:-18000000
> 1900/2:-18000000
> 1900/3:-18000000
> 1900/4:-18000000
> 1900/5:-18000000
> 1900/6:-18000000
> 1900/7:-18000000
> 1900/8:-18000000
> 1900/9:-18000000
> 1900/10:-21600000
> 1900/11:-21600000
>
> The display is year/month#:offset.
> The same program running under the Sun jdk on windows gives me:
> version=1.6.0_07
> vendor=Sun Microsystems Inc.
> java.vm.specification.version=1.0
> java.vm.specification.vendor=Sun Microsystems Inc.
> java.vm.version=10.0-b23
> java.vm.vendor=Sun Microsystems Inc.
> timezone.id=America/Chicago
> date=Mon Jan 01 00:00:00 CST 1900
> 1900/0:-21600000
> 1900/1:-21600000
> 1900/2:-21600000
> 1900/3:-21600000
> 1900/4:-21600000
> 1900/5:-21600000
> 1900/6:-21600000
> 1900/7:-21600000
> 1900/8:-21600000
> 1900/9:-21600000
> 1900/10:-21600000
> 1900/11:-21600000
>

Do you have a simple test case (probably creating a Date object and
printing it would be enough)?
If you want to know what timezone data is actually being used, you can
run something like strace -o out -f java TestApp and the resulting
file, out, will show the C calls being made to open the timezone data
files.
My guess is that the Ubuntu version uses /usr/share/javazi rather than
the OpenJDK timezone data (which, for OpenJDK6, is very outdated -
fixing that is on my TODO list).
This is due to the patch icedtea-use-system-tzdata.patch in IcedTea
which contains:

+  SystemProperty* sp = Arguments::system_properties();
+  // Use the system zoneinfo files, if present
+  Arguments::PropertyList_add (&sp,
+                               new
SystemProperty("user.zoneinfo.dir", "/usr/share/javazi",true));
+

A newer version was submitted upstream but has not yet been approved:

http://mail.openjdk.java.net/pipermail/i18n-dev/2009-August/000136.html

(it's debatable whether such a fix is needed over just a simple symlink).

> Bill
>
> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX ?78751
> 512-275-0344
>
>
> -----Original Message-----
> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
> Sent: Wednesday, December 02, 2009 8:54 AM
> To: Masayoshi Okutsu
> Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>
> 2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
>> What is the time zone ID you are using?
>>
>> Thanks,
>> Masayoshi
>>
>> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>>
>>> From what I can find, this appears to be the right place to post
>>> this, if I'm wrong I would appreciate a pointer to the proper location.
>>> ?The database our app has to talk to has January 1,1900 12:00:00 am
>>> date in it. ?When I load the value into a open jdk date object (using
>>> Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00. ?When I
>>> do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I get
>>> January 1, 1900 12:00:00 am. ?I wrote a test program that prints out
>>> the Timezone info for 1898-1902 and it appears that the open jdk has
>>> a daylight savings time starting on Jan 1, 1900 through Oct 1, 1900
>>> and the sun version doesn't. ?According to Wikipedia, Daylight
>>> savings wasn't suggested until 1907.
>>> ?I can't find anything on the web that suggests where the timezone
>>> info is kept or how complicated it will be to rebuild whatever jar
>>> file is required. Can someone point me to the proper source file and
>>> suggest how involved building the fix will be?
>>> ?Thanks
>>> ???Bill
>>> ?!
>>>
>>> Bill Tims
>>>
>>> Renaissance Systems, Inc.
>>>
>>>
>>>
>>
>
> You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
> If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
> --
> 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
>



-- 
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

From btims at rsitex.com  Wed Dec  2 12:54:07 2009
From: btims at rsitex.com (Bill Tims (RSI))
Date: Wed, 2 Dec 2009 14:54:07 -0600
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
	<17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>
Message-ID: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>

 Andrew

    I've signed up and hopefully this will show up on the list.
    The program is attached.  I ran it, with test2(), with strace and grep'd for javazi and got:

6205  stat64("/usr/share/javazi/ZoneInfoMappings", 0xb7328d4c) = -1 ENOENT (No such file or directory)
...
6205  access("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", R_OK) = 0
6205  stat64("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
6205  open("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", O_RDONLY|O_LARGEFILE) = 5
......
6205  read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"..., 2288) = 2288

If I read this right it is using the CST6CDT file to get the incorrect results.  I'd rather not update the entire jre if I don't have to.  Everything else is working file...so far.

Bill Tims
Renaissance Systems, Inc.
5426 Guadalupe, Suite 100
Austin, TX  78751
512-275-0344
 

-----Original Message-----
From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
Sent: Wednesday, December 02, 2009 2:10 PM
To: Bill Tims (RSI)
Cc: Masayoshi Okutsu; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> Open Jdk Timezone bug?

2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
> Andrew/Masayoshi
>
> ? After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu.

Ok, newer versions will also include the IcedTea version in java -version,

$ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.7pre-r1b34da20e2d1) (build 1.6.0_0-b17) OpenJDK 64-Bit Server VM (build 16.0-b10, mixed mode)

but I think those that use OpenJDK6 b11 are too old to do so.

> The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.

The latest is b17, the number Masayoshi quotes sounds like a version of the proprietary JDK6 (as you are using on Windows, 6u7 in that
case) rather than an OpenJDK6 version.
It would be nice if such responses were posted to the public list...

>
> When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
> 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
> date=Mon Jan 01 00:00:00 CDT 1900
> 1900/0:-18000000
> 1900/1:-18000000
> 1900/2:-18000000
> 1900/3:-18000000
> 1900/4:-18000000
> 1900/5:-18000000
> 1900/6:-18000000
> 1900/7:-18000000
> 1900/8:-18000000
> 1900/9:-18000000
> 1900/10:-21600000
> 1900/11:-21600000
>
> The display is year/month#:offset.
> The same program running under the Sun jdk on windows gives me:
> version=1.6.0_07
> vendor=Sun Microsystems Inc.
> java.vm.specification.version=1.0
> java.vm.specification.vendor=Sun Microsystems Inc.
> java.vm.version=10.0-b23
> java.vm.vendor=Sun Microsystems Inc.
> timezone.id=America/Chicago
> date=Mon Jan 01 00:00:00 CST 1900
> 1900/0:-21600000
> 1900/1:-21600000
> 1900/2:-21600000
> 1900/3:-21600000
> 1900/4:-21600000
> 1900/5:-21600000
> 1900/6:-21600000
> 1900/7:-21600000
> 1900/8:-21600000
> 1900/9:-21600000
> 1900/10:-21600000
> 1900/11:-21600000
>

Do you have a simple test case (probably creating a Date object and printing it would be enough)?
If you want to know what timezone data is actually being used, you can run something like strace -o out -f java TestApp and the resulting file, out, will show the C calls being made to open the timezone data files.
My guess is that the Ubuntu version uses /usr/share/javazi rather than the OpenJDK timezone data (which, for OpenJDK6, is very outdated - fixing that is on my TODO list).
This is due to the patch icedtea-use-system-tzdata.patch in IcedTea which contains:

+  SystemProperty* sp = Arguments::system_properties();  // Use the 
+ system zoneinfo files, if present  Arguments::PropertyList_add (&sp,
+                               new
SystemProperty("user.zoneinfo.dir", "/usr/share/javazi",true));
+

A newer version was submitted upstream but has not yet been approved:

http://mail.openjdk.java.net/pipermail/i18n-dev/2009-August/000136.html

(it's debatable whether such a fix is needed over just a simple symlink).

> Bill
>
> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX ?78751
> 512-275-0344
>
>
> -----Original Message-----
> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] 
> On Behalf Of Andrew John Hughes
> Sent: Wednesday, December 02, 2009 8:54 AM
> To: Masayoshi Okutsu
> Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>
> 2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
>> What is the time zone ID you are using?
>>
>> Thanks,
>> Masayoshi
>>
>> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>>
>>> From what I can find, this appears to be the right place to post 
>>> this, if I'm wrong I would appreciate a pointer to the proper location.
>>> ?The database our app has to talk to has January 1,1900 12:00:00 am 
>>> date in it. ?When I load the value into a open jdk date object 
>>> (using Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00. ?
>>> When I do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I 
>>> get January 1, 1900 12:00:00 am. ?I wrote a test program that prints 
>>> out the Timezone info for 1898-1902 and it appears that the open jdk 
>>> has a daylight savings time starting on Jan 1, 1900 through Oct 1, 
>>> 1900 and the sun version doesn't. ?According to Wikipedia, Daylight 
>>> savings wasn't suggested until 1907.
>>> ?I can't find anything on the web that suggests where the timezone 
>>> info is kept or how complicated it will be to rebuild whatever jar 
>>> file is required. Can someone point me to the proper source file and 
>>> suggest how involved building the fix will be?
>>> ?Thanks
>>> ???Bill
>>> ?!
>>>
>>> Bill Tims
>>>
>>> Renaissance Systems, Inc.
>>>
>>>
>>>
>>
>
> You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
> If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
> --
> 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
>



--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TimezoneTest.java
Type: application/octet-stream
Size: 1982 bytes
Desc: TimezoneTest.java
Url : http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20091202/82c58d74/attachment.obj 

From Masayoshi.Okutsu at Sun.COM  Wed Dec  2 15:33:23 2009
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Thu, 03 Dec 2009 08:33:23 +0900
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
	<17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>
Message-ID: <4B16F943.4090408@sun.com>

Hmm... I don't know why it picks up SystemV/CST6CDT while the detected 
time zone ID is America/Chicago.

Bill, could you set the TZ environment variable to "America/Chicago" and 
run a jre to see what happens?

Thanks,
Masayoshi

On 12/3/2009 5:54 AM, Bill Tims (RSI) wrote:
>  Andrew
>
>     I've signed up and hopefully this will show up on the list.
>     The program is attached.  I ran it, with test2(), with strace and grep'd for javazi and got:
>
> 6205  stat64("/usr/share/javazi/ZoneInfoMappings", 0xb7328d4c) = -1 ENOENT (No such file or directory)
> ...
> 6205  access("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", R_OK) = 0
> 6205  stat64("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
> 6205  open("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", O_RDONLY|O_LARGEFILE) = 5
> ......
> 6205  read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"..., 2288) = 2288
>
> If I read this right it is using the CST6CDT file to get the incorrect results.  I'd rather not update the entire jre if I don't have to.  Everything else is working file...so far.
>
> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX  78751
> 512-275-0344
>  
>
> -----Original Message-----
> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
> Sent: Wednesday, December 02, 2009 2:10 PM
> To: Bill Tims (RSI)
> Cc: Masayoshi Okutsu; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>
> 2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
>   
>> Andrew/Masayoshi
>>
>>   After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu.
>>     
>
> Ok, newer versions will also include the IcedTea version in java -version,
>
> $ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_0"
> OpenJDK Runtime Environment (IcedTea6 1.7pre-r1b34da20e2d1) (build 1.6.0_0-b17) OpenJDK 64-Bit Server VM (build 16.0-b10, mixed mode)
>
> but I think those that use OpenJDK6 b11 are too old to do so.
>
>   
>> The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.
>>     
>
> The latest is b17, the number Masayoshi quotes sounds like a version of the proprietary JDK6 (as you are using on Windows, 6u7 in that
> case) rather than an OpenJDK6 version.
> It would be nice if such responses were posted to the public list...
>
>   
>> When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
>> 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
>> date=Mon Jan 01 00:00:00 CDT 1900
>> 1900/0:-18000000
>> 1900/1:-18000000
>> 1900/2:-18000000
>> 1900/3:-18000000
>> 1900/4:-18000000
>> 1900/5:-18000000
>> 1900/6:-18000000
>> 1900/7:-18000000
>> 1900/8:-18000000
>> 1900/9:-18000000
>> 1900/10:-21600000
>> 1900/11:-21600000
>>
>> The display is year/month#:offset.
>> The same program running under the Sun jdk on windows gives me:
>> version=1.6.0_07
>> vendor=Sun Microsystems Inc.
>> java.vm.specification.version=1.0
>> java.vm.specification.vendor=Sun Microsystems Inc.
>> java.vm.version=10.0-b23
>> java.vm.vendor=Sun Microsystems Inc.
>> timezone.id=America/Chicago
>> date=Mon Jan 01 00:00:00 CST 1900
>> 1900/0:-21600000
>> 1900/1:-21600000
>> 1900/2:-21600000
>> 1900/3:-21600000
>> 1900/4:-21600000
>> 1900/5:-21600000
>> 1900/6:-21600000
>> 1900/7:-21600000
>> 1900/8:-21600000
>> 1900/9:-21600000
>> 1900/10:-21600000
>> 1900/11:-21600000
>>
>>     
>
> Do you have a simple test case (probably creating a Date object and printing it would be enough)?
> If you want to know what timezone data is actually being used, you can run something like strace -o out -f java TestApp and the resulting file, out, will show the C calls being made to open the timezone data files.
> My guess is that the Ubuntu version uses /usr/share/javazi rather than the OpenJDK timezone data (which, for OpenJDK6, is very outdated - fixing that is on my TODO list).
> This is due to the patch icedtea-use-system-tzdata.patch in IcedTea which contains:
>
> +  SystemProperty* sp = Arguments::system_properties();  // Use the 
> + system zoneinfo files, if present  Arguments::PropertyList_add (&sp,
> +                               new
> SystemProperty("user.zoneinfo.dir", "/usr/share/javazi",true));
> +
>
> A newer version was submitted upstream but has not yet been approved:
>
> http://mail.openjdk.java.net/pipermail/i18n-dev/2009-August/000136.html
>
> (it's debatable whether such a fix is needed over just a simple symlink).
>
>   
>> Bill
>>
>> Bill Tims
>> Renaissance Systems, Inc.
>> 5426 Guadalupe, Suite 100
>> Austin, TX  78751
>> 512-275-0344
>>
>>
>> -----Original Message-----
>> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] 
>> On Behalf Of Andrew John Hughes
>> Sent: Wednesday, December 02, 2009 8:54 AM
>> To: Masayoshi Okutsu
>> Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>>
>> 2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
>>     
>>> What is the time zone ID you are using?
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>>       
>>>> From what I can find, this appears to be the right place to post 
>>>> this, if I'm wrong I would appreciate a pointer to the proper location.
>>>>  The database our app has to talk to has January 1,1900 12:00:00 am 
>>>> date in it.  When I load the value into a open jdk date object 
>>>> (using Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00.  
>>>> When I do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I 
>>>> get January 1, 1900 12:00:00 am.  I wrote a test program that prints 
>>>> out the Timezone info for 1898-1902 and it appears that the open jdk 
>>>> has a daylight savings time starting on Jan 1, 1900 through Oct 1, 
>>>> 1900 and the sun version doesn't.  According to Wikipedia, Daylight 
>>>> savings wasn't suggested until 1907.
>>>>  I can't find anything on the web that suggests where the timezone 
>>>> info is kept or how complicated it will be to rebuild whatever jar 
>>>> file is required. Can someone point me to the proper source file and 
>>>> suggest how involved building the fix will be?
>>>>  Thanks
>>>>    Bill
>>>>  !
>>>>
>>>> Bill Tims
>>>>
>>>> Renaissance Systems, Inc.
>>>>
>>>>
>>>>
>>>>         
>> You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
>> If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
>> --
>> 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
>>
>>     
>
>
>
> --
> 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
>   

From gnu_andrew at member.fsf.org  Thu Dec  3 02:03:26 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 3 Dec 2009 10:03:26 +0000
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
	<17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>
Message-ID: <17c6771e0912030203p353c82a1y1e1a25be93f46f9@mail.gmail.com>

2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
> ?Andrew
>
> ? ?I've signed up and hopefully this will show up on the list.
> ? ?The program is attached. ?I ran it, with test2(), with strace and grep'd for javazi and got:
>
> 6205 ?stat64("/usr/share/javazi/ZoneInfoMappings", 0xb7328d4c) = -1 ENOENT (No such file or directory)
> ...
> 6205 ?access("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", R_OK) = 0
> 6205 ?stat64("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
> 6205 ?open("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", O_RDONLY|O_LARGEFILE) = 5
> ......
> 6205 ?read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"..., 2288) = 2288
>

Interesting... so you do have the IcedTea patched version, but Ubuntu
doesn't appear to install any timezone data in /usr/share/javazi.

> If I read this right it is using the CST6CDT file to get the incorrect results. ?I'd rather not update the entire jre if I don't have to. ?Everything else is working file...so far.
>

So OpenJDK6 is the one that's wrong?  It may be that America/Chicago
should be being used, as Masayoshi says, or could just be outdated
timezone data in OpenJDK6.

> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX ?78751
> 512-275-0344
>
>
> -----Original Message-----
> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
> Sent: Wednesday, December 02, 2009 2:10 PM
> To: Bill Tims (RSI)
> Cc: Masayoshi Okutsu; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>
> 2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
>> Andrew/Masayoshi
>>
>> ? After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu.
>
> Ok, newer versions will also include the IcedTea version in java -version,
>
> $ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_0"
> OpenJDK Runtime Environment (IcedTea6 1.7pre-r1b34da20e2d1) (build 1.6.0_0-b17) OpenJDK 64-Bit Server VM (build 16.0-b10, mixed mode)
>
> but I think those that use OpenJDK6 b11 are too old to do so.
>
>> The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.
>
> The latest is b17, the number Masayoshi quotes sounds like a version of the proprietary JDK6 (as you are using on Windows, 6u7 in that
> case) rather than an OpenJDK6 version.
> It would be nice if such responses were posted to the public list...
>
>>
>> When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
>> 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
>> date=Mon Jan 01 00:00:00 CDT 1900
>> 1900/0:-18000000
>> 1900/1:-18000000
>> 1900/2:-18000000
>> 1900/3:-18000000
>> 1900/4:-18000000
>> 1900/5:-18000000
>> 1900/6:-18000000
>> 1900/7:-18000000
>> 1900/8:-18000000
>> 1900/9:-18000000
>> 1900/10:-21600000
>> 1900/11:-21600000
>>
>> The display is year/month#:offset.
>> The same program running under the Sun jdk on windows gives me:
>> version=1.6.0_07
>> vendor=Sun Microsystems Inc.
>> java.vm.specification.version=1.0
>> java.vm.specification.vendor=Sun Microsystems Inc.
>> java.vm.version=10.0-b23
>> java.vm.vendor=Sun Microsystems Inc.
>> timezone.id=America/Chicago
>> date=Mon Jan 01 00:00:00 CST 1900
>> 1900/0:-21600000
>> 1900/1:-21600000
>> 1900/2:-21600000
>> 1900/3:-21600000
>> 1900/4:-21600000
>> 1900/5:-21600000
>> 1900/6:-21600000
>> 1900/7:-21600000
>> 1900/8:-21600000
>> 1900/9:-21600000
>> 1900/10:-21600000
>> 1900/11:-21600000
>>
>
> Do you have a simple test case (probably creating a Date object and printing it would be enough)?
> If you want to know what timezone data is actually being used, you can run something like strace -o out -f java TestApp and the resulting file, out, will show the C calls being made to open the timezone data files.
> My guess is that the Ubuntu version uses /usr/share/javazi rather than the OpenJDK timezone data (which, for OpenJDK6, is very outdated - fixing that is on my TODO list).
> This is due to the patch icedtea-use-system-tzdata.patch in IcedTea which contains:
>
> + ?SystemProperty* sp = Arguments::system_properties(); ?// Use the
> + system zoneinfo files, if present ?Arguments::PropertyList_add (&sp,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new
> SystemProperty("user.zoneinfo.dir", "/usr/share/javazi",true));
> +
>
> A newer version was submitted upstream but has not yet been approved:
>
> http://mail.openjdk.java.net/pipermail/i18n-dev/2009-August/000136.html
>
> (it's debatable whether such a fix is needed over just a simple symlink).
>
>> Bill
>>
>> Bill Tims
>> Renaissance Systems, Inc.
>> 5426 Guadalupe, Suite 100
>> Austin, TX ?78751
>> 512-275-0344
>>
>>
>> -----Original Message-----
>> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com]
>> On Behalf Of Andrew John Hughes
>> Sent: Wednesday, December 02, 2009 8:54 AM
>> To: Masayoshi Okutsu
>> Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>>
>> 2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
>>> What is the time zone ID you are using?
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>>>
>>>> From what I can find, this appears to be the right place to post
>>>> this, if I'm wrong I would appreciate a pointer to the proper location.
>>>> ?The database our app has to talk to has January 1,1900 12:00:00 am
>>>> date in it. ?When I load the value into a open jdk date object
>>>> (using Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00.
>>>> When I do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I
>>>> get January 1, 1900 12:00:00 am. ?I wrote a test program that prints
>>>> out the Timezone info for 1898-1902 and it appears that the open jdk
>>>> has a daylight savings time starting on Jan 1, 1900 through Oct 1,
>>>> 1900 and the sun version doesn't. ?According to Wikipedia, Daylight
>>>> savings wasn't suggested until 1907.
>>>> ?I can't find anything on the web that suggests where the timezone
>>>> info is kept or how complicated it will be to rebuild whatever jar
>>>> file is required. Can someone point me to the proper source file and
>>>> suggest how involved building the fix will be?
>>>> ?Thanks
>>>> ???Bill
>>>> ?!
>>>>
>>>> Bill Tims
>>>>
>>>> Renaissance Systems, Inc.
>>>>
>>>>
>>>>
>>>
>>
>> You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
>> If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
>> --
>> 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
>>
>
>
>
> --
> 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
>



-- 
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

From gnu_andrew at member.fsf.org  Thu Dec  3 02:13:41 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 3 Dec 2009 10:13:41 +0000
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <17c6771e0912030203p353c82a1y1e1a25be93f46f9@mail.gmail.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F786@rsi0ex01.rsi.com>
	<4B149CB6.6000601@sun.com>
	<17c6771e0912020653k7e9a5e60n34cf686b920b82ef@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F799@rsi0ex01.rsi.com>
	<17c6771e0912021209o60d0608av1234abec3d96c519@mail.gmail.com>
	<AB9DACEF700DB541BE6FDF4DCCD91AF939F79B@rsi0ex01.rsi.com>
	<17c6771e0912030203p353c82a1y1e1a25be93f46f9@mail.gmail.com>
Message-ID: <17c6771e0912030213n4d46d688rbbd88080cf55241d@mail.gmail.com>

2009/12/3 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
>> ?Andrew
>>
>> ? ?I've signed up and hopefully this will show up on the list.
>> ? ?The program is attached. ?I ran it, with test2(), with strace and grep'd for javazi and got:
>>
>> 6205 ?stat64("/usr/share/javazi/ZoneInfoMappings", 0xb7328d4c) = -1 ENOENT (No such file or directory)
>> ...
>> 6205 ?access("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", R_OK) = 0
>> 6205 ?stat64("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", {st_mode=S_IFREG|0644, st_size=2288, ...}) = 0
>> 6205 ?open("/usr/lib/jvm/java-6-openjdk/jre/lib/zi/SystemV/CST6CDT", O_RDONLY|O_LARGEFILE) = 5
>> ......
>> 6205 ?read(5, "javazi\0\1\4\10\240\377\337\332\340\35\300\0!\377\340;"..., 2288) = 2288
>>
>
> Interesting... so you do have the IcedTea patched version, but Ubuntu
> doesn't appear to install any timezone data in /usr/share/javazi.
>

It appears you should have this directory from a package 'tzdata-java'
(thanks to Xerxes R?nby for the information).

>> If I read this right it is using the CST6CDT file to get the incorrect results. ?I'd rather not update the entire jre if I don't have to. ?Everything else is working file...so far.
>>
>
> So OpenJDK6 is the one that's wrong? ?It may be that America/Chicago
> should be being used, as Masayoshi says, or could just be outdated
> timezone data in OpenJDK6.
>
>> Bill Tims
>> Renaissance Systems, Inc.
>> 5426 Guadalupe, Suite 100
>> Austin, TX ?78751
>> 512-275-0344
>>
>>
>> -----Original Message-----
>> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On Behalf Of Andrew John Hughes
>> Sent: Wednesday, December 02, 2009 2:10 PM
>> To: Bill Tims (RSI)
>> Cc: Masayoshi Okutsu; i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>>
>> 2009/12/2 Bill Tims (RSI) <btims at rsitex.com>:
>>> Andrew/Masayoshi
>>>
>>> ? After some research it appears that we have the openjdk-6-jre-lib package, version b11, installed and it is current according to Ubuntu.
>>
>> Ok, newer versions will also include the IcedTea version in java -version,
>>
>> $ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_0"
>> OpenJDK Runtime Environment (IcedTea6 1.7pre-r1b34da20e2d1) (build 1.6.0_0-b17) OpenJDK 64-Bit Server VM (build 16.0-b10, mixed mode)
>>
>> but I think those that use OpenJDK6 b11 are too old to do so.
>>
>>> The latest openjdk-6-jre has the same version number. Masayoshi indicates in an earlier email that the current version is 6u17.
>>
>> The latest is b17, the number Masayoshi quotes sounds like a version of the proprietary JDK6 (as you are using on Windows, 6u7 in that
>> case) rather than an OpenJDK6 version.
>> It would be nice if such responses were posted to the public list...
>>
>>>
>>> When I run the app I wrote (I've added a dump of the version info from system properties) that displays the offset for America/Chicago for 1900 I get:
>>> 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
>>> date=Mon Jan 01 00:00:00 CDT 1900
>>> 1900/0:-18000000
>>> 1900/1:-18000000
>>> 1900/2:-18000000
>>> 1900/3:-18000000
>>> 1900/4:-18000000
>>> 1900/5:-18000000
>>> 1900/6:-18000000
>>> 1900/7:-18000000
>>> 1900/8:-18000000
>>> 1900/9:-18000000
>>> 1900/10:-21600000
>>> 1900/11:-21600000
>>>
>>> The display is year/month#:offset.
>>> The same program running under the Sun jdk on windows gives me:
>>> version=1.6.0_07
>>> vendor=Sun Microsystems Inc.
>>> java.vm.specification.version=1.0
>>> java.vm.specification.vendor=Sun Microsystems Inc.
>>> java.vm.version=10.0-b23
>>> java.vm.vendor=Sun Microsystems Inc.
>>> timezone.id=America/Chicago
>>> date=Mon Jan 01 00:00:00 CST 1900
>>> 1900/0:-21600000
>>> 1900/1:-21600000
>>> 1900/2:-21600000
>>> 1900/3:-21600000
>>> 1900/4:-21600000
>>> 1900/5:-21600000
>>> 1900/6:-21600000
>>> 1900/7:-21600000
>>> 1900/8:-21600000
>>> 1900/9:-21600000
>>> 1900/10:-21600000
>>> 1900/11:-21600000
>>>
>>
>> Do you have a simple test case (probably creating a Date object and printing it would be enough)?
>> If you want to know what timezone data is actually being used, you can run something like strace -o out -f java TestApp and the resulting file, out, will show the C calls being made to open the timezone data files.
>> My guess is that the Ubuntu version uses /usr/share/javazi rather than the OpenJDK timezone data (which, for OpenJDK6, is very outdated - fixing that is on my TODO list).
>> This is due to the patch icedtea-use-system-tzdata.patch in IcedTea which contains:
>>
>> + ?SystemProperty* sp = Arguments::system_properties(); ?// Use the
>> + system zoneinfo files, if present ?Arguments::PropertyList_add (&sp,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new
>> SystemProperty("user.zoneinfo.dir", "/usr/share/javazi",true));
>> +
>>
>> A newer version was submitted upstream but has not yet been approved:
>>
>> http://mail.openjdk.java.net/pipermail/i18n-dev/2009-August/000136.html
>>
>> (it's debatable whether such a fix is needed over just a simple symlink).
>>
>>> Bill
>>>
>>> Bill Tims
>>> Renaissance Systems, Inc.
>>> 5426 Guadalupe, Suite 100
>>> Austin, TX ?78751
>>> 512-275-0344
>>>
>>>
>>> -----Original Message-----
>>> From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com]
>>> On Behalf Of Andrew John Hughes
>>> Sent: Wednesday, December 02, 2009 8:54 AM
>>> To: Masayoshi Okutsu
>>> Cc: Bill Tims (RSI); i18n-dev at openjdk.java.net
>>> Subject: Re: <i18n dev> Open Jdk Timezone bug?
>>>
>>> 2009/12/1 Masayoshi Okutsu <Masayoshi.Okutsu at sun.com>:
>>>> What is the time zone ID you are using?
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>>>>
>>>>> From what I can find, this appears to be the right place to post
>>>>> this, if I'm wrong I would appreciate a pointer to the proper location.
>>>>> ?The database our app has to talk to has January 1,1900 12:00:00 am
>>>>> date in it. ?When I load the value into a open jdk date object
>>>>> (using Ubuntu/JBoss 4.2.3 GA-jdk6) I get December 31, 1899 23:00:00.
>>>>> When I do the same thing on my dev box (Win XP/Sun jre 1.6.0_07) I
>>>>> get January 1, 1900 12:00:00 am. ?I wrote a test program that prints
>>>>> out the Timezone info for 1898-1902 and it appears that the open jdk
>>>>> has a daylight savings time starting on Jan 1, 1900 through Oct 1,
>>>>> 1900 and the sun version doesn't. ?According to Wikipedia, Daylight
>>>>> savings wasn't suggested until 1907.
>>>>> ?I can't find anything on the web that suggests where the timezone
>>>>> info is kept or how complicated it will be to rebuild whatever jar
>>>>> file is required. Can someone point me to the proper source file and
>>>>> suggest how involved building the fix will be?
>>>>> ?Thanks
>>>>> ???Bill
>>>>> ?!
>>>>>
>>>>> Bill Tims
>>>>>
>>>>> Renaissance Systems, Inc.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> You don't give any details of the OpenJDK version - what does 'java -version' give on your Ubuntu box?
>>> If this is the system OpenJDK build, then it's an IcedTea build and thus includes a patch to use the system timezone data which is likely to be more up-to-date than that bundled with Sun's JDK.
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>



-- 
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

From btims at rsitex.com  Thu Dec  3 06:31:31 2009
From: btims at rsitex.com (Bill Tims (RSI))
Date: Thu, 3 Dec 2009 08:31:31 -0600
Subject: <i18n dev> Open Jdk Timezone bug?
Message-ID: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79F@rsi0ex01.rsi.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("j
ava.vm.specification.vendor"));
 
System.out.println("java.vm.version="+System.getProperty("java.vm.versio
n"));
 
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

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20091203/37110c8a/attachment-0001.html 

From gnu_andrew at member.fsf.org  Thu Dec  3 07:07:14 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 3 Dec 2009 15:07:14 +0000
Subject: <i18n dev> Open Jdk Timezone bug?
In-Reply-To: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79F@rsi0ex01.rsi.com>
References: <AB9DACEF700DB541BE6FDF4DCCD91AF939F79F@rsi0ex01.rsi.com>
Message-ID: <17c6771e0912030707i49e33391w6c09f2aa04fa4ffd@mail.gmail.com>

2009/12/3 Bill Tims (RSI) <btims at 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

From gnu_andrew at member.fsf.org  Thu Dec 10 10:06:09 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 10 Dec 2009 18:06:09 +0000
Subject: <i18n dev> Security fixes are back;
	other fixes can go in. Time for build 	18?
In-Reply-To: <4B2001D8.8020602@sun.com>
References: <4AF4B948.5070702@sun.com>
	<17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com>
	<4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com>
	<17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com>
	<17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com>
	<4B1E8D68.3090709@sun.com>
	<17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com>
	<17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com>
	<4B2001D8.8020602@sun.com>
Message-ID: <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>

2009/12/9 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Andrew John Hughes wrote:
>>
>> 2009/12/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>
>>>
>>> 2009/12/8 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>
>>>>
>>>> Andrew John Hughes wrote:
>>>>
>>>>>
>>>>> 2009/12/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>
>>>>>
>>>>>>
>>>>>> 2009/12/8 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Joseph D. Darcy wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/11/13 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/11/10 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [snip]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Still need to look at this, but was wondering what was happening
>>>>>>>>>>> with
>>>>>>>>>>> timezone data in 6?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It doesn't seem like much of anything is happening with timezone
>>>>>>>>>> data
>>>>>>>>>> in
>>>>>>>>>> OpenJDK 6!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd appreciate if you could backport these timezone changes.
>>>>>>>>>>
>>>>>>>>>> -Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, no problem.
>>>>>>>>>
>>>>>>>>> So I make it for b18 we still have:
>>>>>>>>>
>>>>>>>>> ?* the issue with the X11 patch I can't apply because of jcheck
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'll check in with Mark, but we're both speaking at Devoxx next week
>>>>>>>> so
>>>>>>>> recognizing Latin-1 characters in jcheck may not happen immediately.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ?* Nimbus issues
>>>>>>>>> ?* the diff issue with HotSpot Martin pointed out
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do we also want the timezone data changes for b18 or shall we do
>>>>>>>>> that
>>>>>>>>> in b19? I think b19's main feature is likely to be hs16.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think the time zone updates would be better in b18; the nature of
>>>>>>>> these
>>>>>>>> changes is very well-understood.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Some time has passed, a few more fixes have come into the repos, and
>>>>>>> I'm
>>>>>>> beginning to think it would better to have OpenJDK 6 b18 be more or
>>>>>>> less
>>>>>>> what is there now and to have the timezone update and other changes
>>>>>>> go
>>>>>>> into
>>>>>>> b19.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sorry, I've been distracted with first the OpenJDK7 release and then
>>>>>> time off work. ?Backporting the timezone stuff should be fairly
>>>>>> trivial. ?I'll have a try today and if it isn't, then we can consider
>>>>>> delaying it.
>>>>>>
>>>>>>
>>>>
>>>> Okay.
>>>>
>>>>
>>>>>>
>>>>>> I think we do need to get the Nimbus fixes in. ?I'm trying to get
>>>>>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the
>>>>>> JAXWS/JAXP changes don't make that a simple job. ?But it's in
>>>>>> progress.
>>>>>>
>>>>>> Is there any news on updating jcheck? ?I still haven't been able to
>>>>>> push the X11 fix.
>>>>>>
>>>>>>
>>>>
>>>> I've pinged Mark but haven't heard back.
>>>>
>>>> Unfortunately, the most expedient way to get this fix back to probably
>>>> to
>>>> ASCII-fy the contributor's name.
>>>>
>>>>
>>>
>>> I've already tried that. ?Whatever jcheck is doing goes beyond ASCII
>>> as it doesn't accept a backtick either (o` is the ASCIIfied version)
>>>
>>> As with other issues with jcheck, if it was open-sourced we wouldn't
>>> have Mark as a bottleneck for fixing the inevitable issues with it.
>>>
>>> This is a fairly serious issue; I currently can't build OpenJDK6
>>> unless I apply that patch first and no doubt others will see this too
>>> (all F12 users for a start).
>>>
>>>
>>>>>>
>>>>>> In response to Erik's e-mail, I'd be happier making HotSpot b16 part
>>>>>> of b19 rather than b18, so we have more time for testing.
>>>>>>
>>>>>>
>>>>
>>>> Yes, the HotSpot upgrade should occur in b19.
>>>>
>>>>
>>>>>>
>>>>>> So still:
>>>>>>
>>>>>> * Timezone fixes
>>>>>> * Nimbus fixes
>>>>>>
>>>>>>
>>>>
>>>> Nimbus backports from JDK 7 I assume.
>>>>
>>>>
>>>
>>> There is one, but I was thinking of the test issues you raised in
>>> previous emails.
>>>
>>>
>>>>>>
>>>>>> * X11 fix
>>>>>>
>>>>>> for b18 from my side. ?Is there some rush to get this out?
>>>>>>
>>>>>>
>>>>
>>>> No rush per se, but with the holiday coming up (including my on vacation
>>>> soon), if the build doesn't happen in the next week or so, it probably
>>>> won't
>>>> happen until January and I'd prefer to get a build with the security
>>>> fixes
>>>> officially out before then.
>>>>
>>>>
>>>
>>> Well, I think most things can probably be sorted this week. ?The X11
>>> fix is the real blocker. ?Can we not just turn jcheck off or something
>>> for one commit?
>>>
>>> I'm currently building OpenJDK6 with the timezone fixes applied and it
>>> looks ok so far. ?I'll post a webrev once it completes.
>>>
>>> There are two more tz issues worthy of consideration that I didn't
>>> include yet because they are not related to the data, but would be
>>> good to have. ?One adds support for old timezone IDs (I'm wary of this
>>> because it introduces a property) and the other fixes an issue with
>>> determining the timezone on GNU/Linux boxes which I believe will
>>> obsolete a different but related fix in IcedTea6. ?I'd also like to
>>> add a simple patch which fixes up the remaining data differences
>>> between 6 and 7 (just typos and revision headers) which seems to have
>>> occurred in the black hole between the OpenJDK6 fork and the OpenJDK7
>>> hg repositories.
>>>
>>> Finally, during build, I just spotted another issue. ?The langtools
>>> build wrongly passes -Werror to javac and this has been removed in the
>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with
>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is
>>> the only building-with-7 issue though.
>>>
>>>
>>>>>
>>>>> Just remembered about Kelly's JDI work; that would be good to get in
>>>>> and being test-related, shouldn't break anything about the build or
>>>>> JDK itself.
>>>>>
>>>>>
>>>>
>>>> There are a bunch of source changes too, but they have been in JDK 7 for
>>>> a
>>>> while so they should be fine for OpenJDK 6.
>>>>
>>>> -Joe
>>>>
>>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>> No sooner did I write that than it built:
>>
>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/
>>
>
> Approved.
>
>> The remaining three tz fixes are:
>>
>> changeset: ? 639:67c41d740e6d
>> user: ? ? ? ?peytoia
>> date: ? ? ? ?Mon Sep 08 15:21:55 2008 +0900
>> summary: ? ? 6466476: (tz) Introduction of tzdata2005r can introduce
>> incompatility issues with some JDK1.1 3-letter TZ Ids
>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d
>>
>> changeset: ? 1693:92b6482e7719
>> user: ? ? ? ?peytoia
>> date: ? ? ? ?Mon Aug 31 14:53:05 2009 +0900
>> summary: ? ? 6456628: (tz) Default timezone is incorrectly set
>> occasionally on Linux
>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719
>>
>>
>
> These other backports approved.
>
>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID.
>>
>
> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this
> change.
>
> Thanks,
>
> -Joe
>

Thanks. All of them are now in OpenJDK6.

There is one more backport lurking in IcedTea6:

http://cr.openjdk.java.net/~andrew/tz/webrev.03/

The actual code fix went in to OpenJDK7 in the black hole between the
two (b22): http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html
 There should be a bug ID as a result -- presumably, you can discover
that internally?

The test case included in the webrev is from Mark Wielaard and is
contributed through Red Hat's SCA.

CCing i18n-dev in case they have any input; it would be nice to have
the test case in 7 too as well as the fix.
-- 
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

From Joe.Darcy at Sun.COM  Thu Dec 10 11:55:01 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 10 Dec 2009 11:55:01 -0800
Subject: <i18n dev> Security fixes are back;
	other fixes can go in. Time for build 18?
In-Reply-To: <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>
References: <4AF4B948.5070702@sun.com>
	<17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com>
	<4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com>
	<17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com>
	<17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com>
	<4B1E8D68.3090709@sun.com>
	<17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com>
	<17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com>
	<4B2001D8.8020602@sun.com>
	<17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>
Message-ID: <4B215215.5050104@sun.com>

Andrew John Hughes wrote:
> 2009/12/9 Joseph D. Darcy <Joe.Darcy at sun.com>:
>   
>> Andrew John Hughes wrote:
>>     
>>> 2009/12/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>
>>>       
>>>> 2009/12/8 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>
>>>>         

[snip]
>>>>
>>>>
>>>>         
>>> No sooner did I write that than it built:
>>>
>>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/
>>>
>>>       
>> Approved.
>>
>>     
>>> The remaining three tz fixes are:
>>>
>>> changeset:   639:67c41d740e6d
>>> user:        peytoia
>>> date:        Mon Sep 08 15:21:55 2008 +0900
>>> summary:     6466476: (tz) Introduction of tzdata2005r can introduce
>>> incompatility issues with some JDK1.1 3-letter TZ Ids
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d
>>>
>>> changeset:   1693:92b6482e7719
>>> user:        peytoia
>>> date:        Mon Aug 31 14:53:05 2009 +0900
>>> summary:     6456628: (tz) Default timezone is incorrectly set
>>> occasionally on Linux
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719
>>>
>>>
>>>       
>> These other backports approved.
>>
>>     
>>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID.
>>>
>>>       
>> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this
>> change.
>>
>> Thanks,
>>
>> -Joe
>>
>>     
>
> Thanks. All of them are now in OpenJDK6.
>
> There is one more backport lurking in IcedTea6:
>
> http://cr.openjdk.java.net/~andrew/tz/webrev.03/
>
> The actual code fix went in to OpenJDK7 in the black hole between the
> two (b22): http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html
>  There should be a bug ID as a result -- presumably, you can discover
> that internally?
>   

Donning my fedora and brandishing a bullwhip, the bug id for this change 
was 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff:

------- TimeZone.java -------
606,610c606
<       if (hasPermission()) {
<           defaultTimeZone = tz;
<       } else {
<           defaultZoneTL.set(tz);
<       }
---
 >       defaultTimeZone = tz;
640a637
 >               defaultZoneTL.set(null);

There was another file involved in this change, 
windows/native/java/util/TimeZone_md.c:

------- TimeZone_md.c -------
199a200
 >         bufSize = sizeof(val);
347c348
<     valueSize = MAX_ZONE_CHAR;
---
 >     valueSize = MAX_MAPID_LENGTH;

This is also the current difference between the OpenJDK 6 and JDK 7 
versions of this file.

> The test case included in the webrev is from Mark Wielaard and is
> contributed through Red Hat's SCA.
>   

There appears to be some test coverage of this change in still-closed 
regression tests.

> CCing i18n-dev in case they have any input; it would be nice to have
> the test case in 7 too as well as the fix.
>   

I'll approve this change going back if the change from the JDK 7 version 
of TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if 
the @bug line in the test includes 6584033.

Thanks,

-Joe

From gnu_andrew at member.fsf.org  Thu Dec 10 13:30:17 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 10 Dec 2009 21:30:17 +0000
Subject: <i18n dev> Security fixes are back;
	other fixes can go in. Time for build 	18?
In-Reply-To: <4B215215.5050104@sun.com>
References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com>
	<17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com>
	<17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com>
	<4B1E8D68.3090709@sun.com>
	<17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com>
	<17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com>
	<4B2001D8.8020602@sun.com>
	<17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>
	<4B215215.5050104@sun.com>
Message-ID: <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com>

2009/12/10 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Andrew John Hughes wrote:
>>
>> 2009/12/9 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>
>>>
>>> Andrew John Hughes wrote:
>>>
>>>>
>>>> 2009/12/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>
>>>>
>>>>>
>>>>> 2009/12/8 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>
>>>>>
>
> [snip]
>>>>>
>>>>>
>>>>>
>>>>
>>>> No sooner did I write that than it built:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/
>>>>
>>>>
>>>
>>> Approved.
>>>
>>>
>>>>
>>>> The remaining three tz fixes are:
>>>>
>>>> changeset: ? 639:67c41d740e6d
>>>> user: ? ? ? ?peytoia
>>>> date: ? ? ? ?Mon Sep 08 15:21:55 2008 +0900
>>>> summary: ? ? 6466476: (tz) Introduction of tzdata2005r can introduce
>>>> incompatility issues with some JDK1.1 3-letter TZ Ids
>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d
>>>>
>>>> changeset: ? 1693:92b6482e7719
>>>> user: ? ? ? ?peytoia
>>>> date: ? ? ? ?Mon Aug 31 14:53:05 2009 +0900
>>>> summary: ? ? 6456628: (tz) Default timezone is incorrectly set
>>>> occasionally on Linux
>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719
>>>>
>>>>
>>>>
>>>
>>> These other backports approved.
>>>
>>>
>>>>
>>>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug
>>>> ID.
>>>>
>>>>
>>>
>>> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for
>>> this
>>> change.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>>
>> Thanks. All of them are now in OpenJDK6.
>>
>> There is one more backport lurking in IcedTea6:
>>
>> http://cr.openjdk.java.net/~andrew/tz/webrev.03/
>>
>> The actual code fix went in to OpenJDK7 in the black hole between the
>> two (b22):
>> http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html
>> ?There should be a bug ID as a result -- presumably, you can discover
>> that internally?
>>
>
> Donning my fedora and brandishing a bullwhip, the bug id for this change was
> 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff:
>
> ------- TimeZone.java -------
> 606,610c606
> < ? ? ? if (hasPermission()) {
> < ? ? ? ? ? defaultTimeZone = tz;
> < ? ? ? } else {
> < ? ? ? ? ? defaultZoneTL.set(tz);
> < ? ? ? }
> ---
>> ? ? ? defaultTimeZone = tz;
> 640a637
>> ? ? ? ? ? ? ? defaultZoneTL.set(null);
>
> There was another file involved in this change,
> windows/native/java/util/TimeZone_md.c:
>
> ------- TimeZone_md.c -------
> 199a200
>> ? ? ? ? bufSize = sizeof(val);
> 347c348
> < ? ? valueSize = MAX_ZONE_CHAR;
> ---
>> ? ? valueSize = MAX_MAPID_LENGTH;
>
> This is also the current difference between the OpenJDK 6 and JDK 7 versions
> of this file.
>
>> The test case included in the webrev is from Mark Wielaard and is
>> contributed through Red Hat's SCA.
>>
>
> There appears to be some test coverage of this change in still-closed
> regression tests.
>
>> CCing i18n-dev in case they have any input; it would be nice to have
>> the test case in 7 too as well as the fix.
>>
>
> I'll approve this change going back if the change from the JDK 7 version of
> TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if the
> @bug line in the test includes 6584033.
>
> Thanks,
>
> -Joe
>

I added the fixes mentioned and tried to push. I was greeted with this:

remote:
remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh:
Executable files not permitted
remote:

Funny because:

$ find test -name '*.sh'|wc -l
305

And no it isn't because of the executable permission bit, I did a
chmod -x to be sure and it still didn't push :(
-- 
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

From martinrb at google.com  Thu Dec 10 17:06:26 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 10 Dec 2009 17:06:26 -0800
Subject: <i18n dev> Security fixes are back;
	other fixes can go in. Time for build 	18?
In-Reply-To: <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com>
References: <4AF4B948.5070702@sun.com>
	<17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com>
	<17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com>
	<4B1E8D68.3090709@sun.com>
	<17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com>
	<17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com>
	<4B2001D8.8020602@sun.com>
	<17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>
	<4B215215.5050104@sun.com>
	<17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com>
Message-ID: <1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com>

On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:
> 2009/12/10 Joseph D. Darcy <Joe.Darcy at sun.com>:
> I added the fixes mentioned and tried to push. I was greeted with this:
>
> remote:
> remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh:
> Executable files not permitted
> remote:
>
> Funny because:
>
> $ find test -name '*.sh'|wc -l
> 305
>
> And no it isn't because of the executable permission bit, I did a
> chmod -x to be sure and it still didn't push :(

I ran into jcheck executable file refusal for .sh files, and for me,
chmod -x did work.  Did you forget to "hg qrefresh" after fixing
up the permissions (I'm leaving out some details)?

Martin

From gnu_andrew at member.fsf.org  Fri Dec 11 07:30:48 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 11 Dec 2009 15:30:48 +0000
Subject: <i18n dev> Security fixes are back;
	other fixes can go in. Time for build 	18?
In-Reply-To: <1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com>
References: <4AF4B948.5070702@sun.com>
	<17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com>
	<4B1E8D68.3090709@sun.com>
	<17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com>
	<17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com>
	<4B2001D8.8020602@sun.com>
	<17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com>
	<4B215215.5050104@sun.com>
	<17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com>
	<1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com>
Message-ID: <17c6771e0912110730x6638a86cwc399f786843fff3a@mail.gmail.com>

2009/12/11 Martin Buchholz <martinrb at google.com>:
> On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>> 2009/12/10 Joseph D. Darcy <Joe.Darcy at sun.com>:
>> I added the fixes mentioned and tried to push. I was greeted with this:
>>
>> remote:
>> remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh:
>> Executable files not permitted
>> remote:
>>
>> Funny because:
>>
>> $ find test -name '*.sh'|wc -l
>> 305
>>
>> And no it isn't because of the executable permission bit, I did a
>> chmod -x to be sure and it still didn't push :(
>
> I ran into jcheck executable file refusal for .sh files, and for me,
> chmod -x did work. ?Did you forget to "hg qrefresh" after fixing
> up the permissions (I'm leaving out some details)?
>
> Martin
>

Doh! Rolling it back and doing the chmod -x worked.  Thanks Martin!
-- 
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