From keiths at redhat.com  Mon Sep 10 13:10:45 2007
From: keiths at redhat.com (Keith Seitz)
Date: Mon, 10 Sep 2007 13:10:45 -0700
Subject: <i18n dev> Using system tzdata
In-Reply-To: <46C3AE39.3010200@sun.com>
References: <200708090008.l7908GHP025455@ribbit.SFBay.Sun.COM>
	<46C32F4E.1050006@redhat.com> <46C3AE39.3010200@sun.com>
Message-ID: <46E5A4C5.9080904@redhat.com>

Masayoshi Okutsu wrote:
> Sorry for taking time to respond.

Likewise!

> I've filed an RFE for this request to 
> make sure Sun's JRE supports the same mechanism. Sun's Change Request ID 
> (aka bug ID) is 6593486.

I'll add my comments/patch there, too, but I wanted to briefly let you 
know what I've been up to with all of this.

>     * I think the "java." name space should be avoided for this purpose.
>       "user.timezone.dir" should be OK.

Done.

>     * I'd also suggest that "/usr/share/zoneinfo/java" be changed to
>       something like "/usr/share/javazi" because Java runtime may search
>       files under /usr/share/zoneinfo to detect the platform time zone
>       setting. It costs extra to skip all the files under
>       /usr/share/zoneinfo/java if the directory comes before other
>       directories in /usr/share/zoneinfo. Also I think
>       /usr/share/zoneinfo should contain the native Olson time zone data
>       files only.

Done.

>     * I'm not sure if the current implementation is robust enough to be
>       able to reject all broken data files. It does check magic numbers,
>       though. You may need extra tests with random directory paths. Or
>       you could add more checking to see if the directory is right, such
>       as existence of the ZoneInfoMappings file.

I've added a little something so that the code will check for a 
ZoneInfoMappings file before using the user.timezone.dir property. 
Beyond this, there seems little reason to do any more extreme error 
checking. The default is still to use the supplied, built-in tzdata. If 
the user sets user.timezone.dir to something else, he should be aware of 
what he is doing!

Thank you for your feedback,
Keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: use-tzdata.patch
Type: text/x-patch
Size: 1782 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20070910/08064cd1/attachment.bin 

From Tom.Marble at Sun.COM  Wed Sep 19 08:28:04 2007
From: Tom.Marble at Sun.COM (Tom Marble)
Date: Wed, 19 Sep 2007 10:28:04 -0500
Subject: <i18n dev> Test of Gmane
Message-ID: <46F14004.5030508@sun.com>

Hi:

This is a test message.

If all goes well this message will soon appear in:
http://news.gmane.org/gmane.comp.java.openjdk.i18n.devel

Regards,

--Tom


From keiths at redhat.com  Wed Sep 19 11:28:33 2007
From: keiths at redhat.com (Keith Seitz)
Date: Wed, 19 Sep 2007 11:28:33 -0700
Subject: <i18n dev> Using system tzdata
In-Reply-To: <46E5A4C5.9080904@redhat.com>
References: <200708090008.l7908GHP025455@ribbit.SFBay.Sun.COM>
	<46C32F4E.1050006@redhat.com> <46C3AE39.3010200@sun.com>
	<46E5A4C5.9080904@redhat.com>
Message-ID: <46F16A51.80705@redhat.com>

Ping?
[I have not yet updated the RFE. I'm going to await further feedback.]

Keith Seitz wrote:
> Masayoshi Okutsu wrote:
>> Sorry for taking time to respond.
> 
> Likewise!
> 
>> I've filed an RFE for this request to make sure Sun's JRE supports the 
>> same mechanism. Sun's Change Request ID (aka bug ID) is 6593486.
> 
> I'll add my comments/patch there, too, but I wanted to briefly let you 
> know what I've been up to with all of this.
> 
>>     * I think the "java." name space should be avoided for this purpose.
>>       "user.timezone.dir" should be OK.
> 
> Done.
> 
>>     * I'd also suggest that "/usr/share/zoneinfo/java" be changed to
>>       something like "/usr/share/javazi" because Java runtime may search
>>       files under /usr/share/zoneinfo to detect the platform time zone
>>       setting. It costs extra to skip all the files under
>>       /usr/share/zoneinfo/java if the directory comes before other
>>       directories in /usr/share/zoneinfo. Also I think
>>       /usr/share/zoneinfo should contain the native Olson time zone data
>>       files only.
> 
> Done.
> 
>>     * I'm not sure if the current implementation is robust enough to be
>>       able to reject all broken data files. It does check magic numbers,
>>       though. You may need extra tests with random directory paths. Or
>>       you could add more checking to see if the directory is right, such
>>       as existence of the ZoneInfoMappings file.
> 
> I've added a little something so that the code will check for a 
> ZoneInfoMappings file before using the user.timezone.dir property. 
> Beyond this, there seems little reason to do any more extreme error 
> checking. The default is still to use the supplied, built-in tzdata. If 
> the user sets user.timezone.dir to something else, he should be aware of 
> what he is doing!
> 
> Thank you for your feedback,
> Keith
>