Ticket #5975 (closed enhancement: fixed)

Bug contains 8 commit(s) | SVN Diffs for #5975

 

Opened 1 year ago

Last modified 5 months ago

Use of Java TimeZone in ICU4J

Reported by: yoshito Assigned to: yoshito
Priority: major Milestone: 3.9.2
Component: time_calc Version:
Keywords: Cc:
Load: Xref:
Java Version: Operating System:
Project (C/J): ICU4J Weeks: 1
Review: srl

Description

Until recently, JVM vendors were lazy to update time zone rules. Since North America DST change in 2007, JVM vendors pay more attention to time zone rule changes and they are now delivering tzdata patch in timely manner.

In reality, many ICU4J clients have to deal both Java and ICU4J TimeZone. Because ICU4J has own time zone rule data, they have to apply tzdata update patch to both JVM and ICU4J.

There are some benefits to have own tzdata in ICU. For example, ICU allows users to access time zone transitions and rules. This features can be implemented in ICU, because ICU has its own tzdata. But, majority of ICU4J users do no need such advanced features. For those users who do not need advanced time zone features would be good enough with Java TimeZone. They would rather prefer to less maintenance effort.

This ticket proposes ICU4J to support Java TimeZone as primary TimeZone implementation in ICU4J. Actual tasks would be -

1. Add a class extending com.ibm.icu.util.TimeZone. Implementation of time zone operation in the new class actually calls methods in java.util.TimeZone.
2. Create a global switch to alter the behavior of com.ibm.icu.util.TimeZone#getTimeZone. The switch may be implemented as a static method in com.ibm.icu.util.TimeZone or external configuration file.

Attachments

Change History

10/02/07 10:32:54 changed by yoshito

  • owner changed from somebody to yoshito.

(follow-up: ↓ 6 ) 10/02/07 11:02:29 changed by markus

Some users avoid the dual-update problem by using only the ICU4J TimeZone class where it matters. That's what we advertise: Use ICU (and keep it up to date) and you get the most up-to-date time zone and Unicode and CLDR... behavior.

I think it's ok to add a new wrapper class and a switch, but the default behavior should be as before: getTimeZone() should by default return an instance of ICU's TimeZone class.

10/02/07 11:51:02 changed by yoshito

In many cases, application developers utilize existing software components/libraries developed by third parties. Even he/she wants to use ICU4J for his/her own Java code, he/she may not be able to modify components/libraries developed by third parties. In this case, his/her decision could be - not using ICU4J because of the maintenance/consistency problem. The primary goal for this ticket is to lower the bar for adopting ICU4J.

I'm not proposing the out of box default to be Java TimeZone. However, the ICU4J clients should be able to control the default behavior globally.

01/07/08 12:14:16 changed by yoshito

  • milestone changed from 4.0 to 3.9.2.

01/07/08 12:47:04 changed by yoshito

  • weeks changed from 1.5 to 1.

(in reply to: ↑ 2 ) 02/06/08 13:46:05 changed by yoshito

Replying to markus:

Some users avoid the dual-update problem by using only the ICU4J TimeZone class where it matters. That's what we advertise: Use ICU (and keep it up to date) and you get the most up-to-date time zone and Unicode and CLDR... behavior.

Also, ICU4J depends on underlying JVM's default zone detection. A certain type of change (such as Argentina timezone patch on Windows) requires JVM patch. Thus, updating ICU4J timezone data alone does not work always (you cannot avoid double update problem even you use ICU4J TimeZone only). Also, these days, Java vendors provide up-to-date tzdata in time (sometimes, earlier than Olson tzdata official release).

03/10/08 16:41:09 changed by srl

reviewed icu4j/branches/yoshito/javatz at r23528 to icu4j/trunk at r23528

03/11/08 00:19:19 changed by yoshito

  • revw set to srl.

06/27/08 17:34:50 changed by srl

  • status changed from new to closed.
  • resolution set to fixed.

Add/Change #5975 (Use of Java TimeZone in ICU4J)




Anti spam check: