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 >
