Asia/Colombo is supported by ICU and all the timezones in TimeZones class are supported by ICU as well. The reason why they are in TimeZones is that they will be used as cache for timezones in ICU. The instances of timezone derived from ICU should be converted into SimpleTimeZone instances of our class. That's why we use a cache to store the instances of SimpleTimeZone from TimeZones. They are a just a subset of timezones in ICU.
2008/7/17 Nathan Beyer <[EMAIL PROTECTED]>: > I'm still confused. Is Asia/Colombo supported by ICU? Assuming it is, it > shouldn't be in TimeZone at all, correct? > > I thought we were completely deferring everything to ICU. In other words, > TimeZone is just a wrapper for ICU. > > -Nathan > > On Tue, Jul 15, 2008 at 11:23 PM, Jim Yu <[EMAIL PROTECTED]> wrote: > > > Asia/Colombo does exist in TimeZones class but with wrong raw offset > value. > > So it needs to be corrected. Since we will add all the timezones in > > TimeZones > > class into the cache, it will be addded into the cache directly from > > TimeZones, > > there is no need to derive it from ICU any more. > > 2008/7/16 Nathan Beyer <[EMAIL PROTECTED]>: > > > > > Okay, so what's up with this bug [1]. Is Asia/Colombo not in ICU? > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5909 > > > > > > On Mon, Jul 14, 2008 at 11:25 PM, Jim Yu <[EMAIL PROTECTED]> > wrote: > > > > > > > Hi Nathan, > > > > Yes, all supported time zones are availble from TimeZone.getTimeZones > > > since > > > > we will return all of them derived from ICU. Currently, our > > > implementation > > > > of timezones > > > > actually delegate to ICU. For those timezones in TimeZones class, > they > > > will > > > > be added > > > > into a "cache". And for those missing timezones in TimeZones class, > > > > they will be lazy > > > > instantialized when required by deriving them from ICU and then added > > > into > > > > the cache. > > > > Therefore, we just need to keep those timezones in TimeZones class > > > > consistent with > > > > ICU. To complement the missing timezones will only bring us > additional > > > work > > > > for > > > > maintenance if ICU implementation changes. > > > > 2008/7/15 Nathan Beyer <[EMAIL PROTECTED]>: > > > > > > > > > Beyond the style issues of setting the time offset, is there an > > > > underlying > > > > > issue with what TimeZone instances are returned by getTimeZones. I > > > don't > > > > > quite understand the 'missing from TimeZones, but will be lazily > > > > > instantiated by ICU'. Does this mean it's a ICU supported time > zone, > > or > > > a > > > > > custom time zone? We need to make sure that all supported time > zones > > > are > > > > > available from TimeZone.getTimeZones; there's a lot of code that > > > depends > > > > on > > > > > this functionality to enumerate time zones. > > > > > > > > > > -Nathan > > > > > > > > > > On Mon, Jul 14, 2008 at 3:28 AM, Jim Yu <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > Hi Senaka, > > > > > > > > > > > > I made a further investigation[1] on this issue. It indicates > only > > > > > > "Asia/Colombo " needs to be > > > > > > corrected. For those existing timezones which are not expressed > by > > > > > integer > > > > > > number hours, > > > > > > they currently look like this: > > > > > > > > > > > > new SimpleTimeZone(9 * ONE_HOUR + 1800000, "ACT"), //$NON-NLS-1$ > > > > > > > > > > > > I don't think it does make sense to do additional work such as > > > > replacing > > > > > > 1800000 by HALF_HOUR. > > > > > > > > > > > > [1] > > > > > > T: means it is correct in TimeZones > > > > > > F: means it is in incorrect in TimeZones > > > > > > M: means it is missing in TimeZones but will be lazy instantiated > > > from > > > > > ICU > > > > > > in TimeZone. > > > > > > So it will be correct since it keeps consistent with ICU. > > > > > > > > > > > > T ACT >> 34200000 millisecs 9.5 hours > > > > > > T Asia/Calcutta >> 19800000 millisecs 5.5 hours > > > > > > F Asia/Colombo >> 19800000 millisecs 5.5 hours > > > > > > T Asia/Kabul >> 16200000 millisecs 4.5 hours > > > > > > T Asia/Katmandu >> 20700000 millisecs 5.75 hours > > > > > > T Asia/Rangoon >> 23400000 millisecs 6.5 hours > > > > > > M Asia/Riyadh87 >> 11224000 millisecs 3.117777777777778 hours > > > > > > M Asia/Riyadh88 >> 11224000 millisecs 3.117777777777778 hours > > > > > > M Asia/Riyadh89 >> 11224000 millisecs 3.117777777777778 hours > > > > > > T Asia/Tehran >> 12600000 millisecs 3.5 hours > > > > > > T Australia/Adelaide >> 34200000 millisecs 9.5 hours > > > > > > T Australia/Broken_Hill >> 34200000 millisecs 9.5 hours > > > > > > T Australia/Darwin >> 34200000 millisecs 9.5 hours > > > > > > M Australia/Eucla >> 31500000 millisecs 8.75 hours > > > > > > M Australia/LHI >> 37800000 millisecs 10.5 hours > > > > > > T Australia/Lord_Howe >> 37800000 millisecs 10.5 hours > > > > > > M Australia/North >> 34200000 millisecs 9.5 hours > > > > > > M Australia/South >> 34200000 millisecs 9.5 hours > > > > > > M Australia/Yancowinna >> 34200000 millisecs 9.5 hours > > > > > > T IST >> 19800000 millisecs 5.5 hours > > > > > > T Indian/Cocos >> 23400000 millisecs 6.5 hours > > > > > > M Iran >> 12600000 millisecs 3.5 hours > > > > > > M Mideast/Riyadh87 >> 11224000 millisecs 3.117777777777778 > hours > > > > > > M Mideast/Riyadh88 >> 11224000 millisecs 3.117777777777778 > hours > > > > > > M Mideast/Riyadh89 >> 11224000 millisecs 3.117777777777778 > hours > > > > > > M NZ-CHAT >> 45900000 millisecs 12.75 hours > > > > > > T Pacific/Chatham >> 45900000 millisecs 12.75 hours > > > > > > T Pacific/Norfolk >> 41400000 millisecs 11.5 hours > > > > > > > > > > > > 2008/7/14 Senaka Fernando <[EMAIL PROTECTED]>: > > > > > > > > > > > > > Hi Jim, > > > > > > > > > > > > > > Agreed. That is infact a special case. :)... So as you say, > along > > > > with > > > > > a > > > > > > > comment, we might as well define this. But, there are a > > reasonable > > > > > amount > > > > > > > of > > > > > > > time zones that are 1/2 hours apart. Thus, at least, ONE_HOUR > and > > > > > > HALF_HOUR > > > > > > > is better to have according to my belief. > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > Regards, > > > > > > > Senaka > > > > > > > > > > > > > > On Sun, Jul 13, 2008 at 8:41 PM, Jim Yu <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > > Hi, Senaka, > > > > > > > > I took a look at the raw offsets to UTC for all timezones in > > ICU. > > > > It > > > > > > > seems > > > > > > > > there are only quite a few of them > > > > > > > > can't be expressed by hours in integer[1]. I don't think > > define > > > > more > > > > > > > > constants such as HALF_HOUR will > > > > > > > > make sense since there are timezones which can't be expressed > > in > > > > > this > > > > > > > way. > > > > > > > > E.g. Asia/Riyadh87Asia/Riyadh87 whose raw offset is 11224000. > > > > > > > > Moreover, there are many timezones missing in TimeZones class > > > will > > > > be > > > > > > > lazy > > > > > > > > initialized from ICU in TimeZone. > > > > > > > > For those timezones, we will get the correct raw offset from > > ICU. > > > > > > > > Therefore, > > > > > > > > for timezones which already exist > > > > > > > > in TimeZones that can't be expressed by hours in interger, I > > > > suggest > > > > > we > > > > > > > > just > > > > > > > > initialize them directly like this: > > > > > > > > new SimpleTimeZone(20700000, XXX). > > > > > > > > After all, using constant like ONE_HOUR is only for reading > > > > > > convenience. > > > > > > > > > > > > > > > > [1] > > > > > > > > ACTACT >> 34200000 millisecs 9.5 hours > > > > > > > > Asia/CalcuttaAsia/Calcutta >> 19800000 millisecs 5.5 hours > > > > > > > > Asia/ColomboAsia/Colombo >> 19800000 millisecs 5.5 hours > > > > > > > > Asia/KabulAsia/Kabul >> 16200000 millisecs 4.5 hours > > > > > > > > Asia/KatmanduAsia/Katmandu >> 20700000 millisecs 5.75 hours > > > > > > > > Asia/RangoonAsia/Rangoon >> 23400000 millisecs 6.5 hours > > > > > > > > Asia/Riyadh87Asia/Riyadh87 >> 11224000 millisecs > > > 3.117777777777778 > > > > > > hours > > > > > > > > Asia/Riyadh88Asia/Riyadh88 >> 11224000 millisecs > > > 3.117777777777778 > > > > > > hours > > > > > > > > Asia/Riyadh89Asia/Riyadh89 >> 11224000 millisecs > > > 3.117777777777778 > > > > > > hours > > > > > > > > Asia/TehranAsia/Tehran >> 12600000 millisecs 3.5 hours > > > > > > > > Australia/AdelaideAustralia/Adelaide >> 34200000 millisecs > 9.5 > > > > hours > > > > > > > > Australia/Broken_HillAustralia/Broken_Hill >> 34200000 > > millisecs > > > > 9.5 > > > > > > > hours > > > > > > > > Australia/DarwinAustralia/Darwin >> 34200000 millisecs 9.5 > > hours > > > > > > > > Australia/EuclaAustralia/Eucla >> 31500000 millisecs 8.75 > hours > > > > > > > > Australia/LHIAustralia/LHI >> 37800000 millisecs 10.5 hours > > > > > > > > Australia/Lord_HoweAustralia/Lord_Howe >> 37800000 millisecs > > 10.5 > > > > > hours > > > > > > > > Australia/NorthAustralia/North >> 34200000 millisecs 9.5 > hours > > > > > > > > Australia/SouthAustralia/South >> 34200000 millisecs 9.5 > hours > > > > > > > > Australia/YancowinnaAustralia/Yancowinna >> 34200000 > millisecs > > > 9.5 > > > > > > hours > > > > > > > > ISTIST >> 19800000 millisecs 5.5 hours > > > > > > > > Indian/CocosIndian/Cocos >> 23400000 millisecs 6.5 hours > > > > > > > > IranIran >> 12600000 millisecs 3.5 hours > > > > > > > > Mideast/Riyadh87Mideast/Riyadh87 >> 11224000 millisecs > > > > > > 3.117777777777778 > > > > > > > > hours > > > > > > > > Mideast/Riyadh88Mideast/Riyadh88 >> 11224000 millisecs > > > > > > 3.117777777777778 > > > > > > > > hours > > > > > > > > Mideast/Riyadh89Mideast/Riyadh89 >> 11224000 millisecs > > > > > > 3.117777777777778 > > > > > > > > hours > > > > > > > > NZ-CHATNZ-CHAT >> 45900000 millisecs 12.75 hours > > > > > > > > Pacific/ChathamPacific/Chatham >> 45900000 millisecs 12.75 > > hours > > > > > > > > Pacific/NorfolkPacific/Norfolk >> 41400000 millisecs 11.5 > hours > > > > > > > > 2008/7/13 Senaka Fernando <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > > Hi Nathan, Tharindu, > > > > > > > > > > > > > > > > > > Kathmandu, Nepal is at UTC +5.45. > > > > > > > > > > > > > > > > > > Therefore, we should perhaps also have a QUARTER_HOUR as > > well. > > > > > > > > > > > > > > > > > > I will work on including all popular cities that are not > > listed > > > > at > > > > > > the > > > > > > > > > moment. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Senaka > > > > > > > > > > > > > > > > > > On Sun, Jul 13, 2008 at 12:27 AM, Nathan Beyer < > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Floats should not be needed, nor would they be precise. > > The > > > > > offset > > > > > > > is > > > > > > > > > based > > > > > > > > > > on the number of milliseconds. > > > > > > > > > > > > > > > > > > > > I believe the code example showed something like this - > > > > > > > > > > > > > > > > > > > > new SimpleTimeZone(6 * ONE_HOUR, XXX) > > > > > > > > > > > > > > > > > > > > To do a half you could just create a new constant and do > > > > > something > > > > > > > like > > > > > > > > > > this > > > > > > > > > > - > > > > > > > > > > > > > > > > > > > > new SimpleTimeZone(5 * ONE_HOUR + HALF_HOUR, XXX) > > > > > > > > > > > > > > > > > > > > -Nathan > > > > > > > > > > > > > > > > > > > > On Sat, Jul 12, 2008 at 8:28 AM, Senaka Fernando < > > > > > > > [EMAIL PROTECTED]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Tharindu, > > > > > > > > > > > > > > > > > > > > > > Isn't com.ibm.icu.util.SimpleTimeZone accepting the > > offset > > > as > > > > > the > > > > > > > > > number > > > > > > > > > > of > > > > > > > > > > > milliseconds that a time zone is apart from UTC? Am I > > > > mistaken > > > > > > > here? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Senaka > > > > > > > > > > > > > > > > > > > > > > On Sat, Jul 12, 2008 at 5:04 PM, Tharindu Mathew < > > > > > > > > [EMAIL PROTECTED]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > The problem as I pointed out in the JIRA is that, > > floats > > > > are > > > > > > not > > > > > > > > > > accepted > > > > > > > > > > > > as > > > > > > > > > > > > arguments to this method cause some classes from an > IBM > > > > > package > > > > > > > is > > > > > > > > > > used, > > > > > > > > > > > in > > > > > > > > > > > > which the source CAN'T be modified (non-harmony). > This > > > was > > > > > what > > > > > > I > > > > > > > > > > > > understood > > > > > > > > > > > > from the problem. > > > > > > > > > > > > > > > > > > > > > > > > Therefore only, whole values are set, because only > > > integers > > > > > are > > > > > > > > > > accepted > > > > > > > > > > > > through the method from the IBM package. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Tharindu > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jul 12, 2008 at 3:06 PM, Senaka Fernando < > > > > > > > > > [EMAIL PROTECTED]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to know why, > > > > > java.util.TimeZones.getTimeZones() > > > > > > > only > > > > > > > > > > > > retrieves > > > > > > > > > > > > > Time Zones that are a whole number of hours apart > > from > > > > UTC? > > > > > > If > > > > > > > > this > > > > > > > > > > was > > > > > > > > > > > > not > > > > > > > > > > > > > intentional, I would like to volunteer to create > > > entries > > > > > for > > > > > > > all > > > > > > > > > Time > > > > > > > > > > > > Zones > > > > > > > > > > > > > that are not listed, which are not a whole number > of > > > > hours > > > > > > > > > > (fractional) > > > > > > > > > > > > > apart from UTC. Thanks, to Tharindu for locating > this > > > > > issue, > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > https://issues.apache.org/jira/browse/HARMONY-5909 > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > Senaka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best Regards, > > > > > > > > Jim, Jun Jie Yu > > > > > > > > > > > > > > > > China Software Development Lab, IBM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best Regards, > > > > > > Jim, Jun Jie Yu > > > > > > > > > > > > China Software Development Lab, IBM > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > > > Jim, Jun Jie Yu > > > > > > > > China Software Development Lab, IBM > > > > > > > > > > > > > > > -- > > Best Regards, > > Jim, Jun Jie Yu > > > > China Software Development Lab, IBM > > > -- Best Regards, Jim, Jun Jie Yu China Software Development Lab, IBM
