Hello Jim, all, It's nice to see that you are digging the timezones further. I believe the second approach is better because we have already noticed on the list that different sources may understand timezones differently, and establishing compatibility between RI and ICU is just a second priority compared to the proper functionality.
The second approach is also nice because it may be evolutionary evolved into the first one by getting more and more timezones from ICU. This is even more nice, because people usually work with few timezones, so lazy initialization approach is better than initializing all of them. Thanks. On Tue, Jun 3, 2008 at 3:14 PM, Jim Yu <[EMAIL PROTECTED]> wrote: > Hi all, > > If we run a simple comparison of RI's time zone IDs with Harmony's, we will > find there are quite a few in the same category. > I suggest that we need to complement the missing TimeZone IDs. Two solutions > in my mind: > > [1] We load the TimeZone IDs into available zones cache via ICU completely > and don't use the available zones initialized by TimeZones > any more. But for this solution, many testcase will fail since they based on > the behavior of those TimeZone instances initialized by > TimeZones. So we need to check each failure testcase and identify which > behavior is more reasonable, instances of TimeZones or > those of ICU? > > [2] We just do a small trick. When there is a missing TimeZone ID > which exists in ICU, we add it into available zones cache in TimeZone. > So it will be found from now on. For this solution, almost all the testcase > will succeed since instances of TimeZones are still working. > > I think [2] is a simple fix, although [1] is also reasonable since we can > totally delegate to ICU. Personally I'd go with [2]. > > -- > Best Regards, > Jim, Jun Jie Yu > > China Software Development Lab, IBM > -- With best regards, Alexei
