Hi Okutsu-san,
Thank you for your proposal. Yes, the TimeZone class has some built-in
assumptions which cause many problems. I had been planning to introduce
some methods, one of which is very similar to your proposal, mainly for
fixing the disambiguation problem during the standard-daylight t
I agree that the revised one is reasonable.
Thanks,
Masayoshi
On 8/14/2008 4:14 AM, Yoshito Umaoka wrote:
Oops.. stupid mistake in the previous note..
> public void getOffset(long date, int[] offsets) {
> if (offsets == null || offsets.length < 2) {
> offsets = new int[2];
> }
Hi Umaoka-san,
Thank you for your proposal. Yes, the TimeZone class has some built-in
assumptions which cause many problems. I had been planning to introduce
some methods, one of which is very similar to your proposal, mainly for
fixing the disambiguation problem during the standard-daylight t
Oops.. stupid mistake in the previous note..
> public void getOffset(long date, int[] offsets) {
> if (offsets == null || offsets.length < 2) {
> offsets = new int[2];
> }
> if (inDaylightTime(new Date(date)) {
> offsets[1] = getDSTSavings();
> offsets[0] = get
Hello all,
I'm experiencing a problem for setting my own TimeZone implementation as
system default time zone. After some investigation, I think this
problem is caused by the lack of API in java.util.TimeZone.
When TimeZone was introduced in JDK 1.1, it did not support historical
GMT offsets
