The former, would require implicit casts to double, floating point division and then an explicit cast back to long, which is workable, but I think it just makes the code overly complex. The later is fine, as it's integer division, but I think just using a couple of constants with integer multiplication is the most clear.
final int QUARTER_ONE_HOUR = 1000 * 60 * 15; final int HALF_ONE_HOUR = QUARTER_ONE_HOUR * 2; final int ONE_HOUR = HALF_ONE_HOUR * 2; Aside from avoiding floating point conversions, multiplication versus division is a style issue. Just make it clean and obvious. -Nathan On Sun, Jul 13, 2008 at 4:53 AM, Alex Blewitt <[EMAIL PROTECTED]> wrote: > Why not just do 5.75* One_hour ? Or one_hour/4? > > Alex > > Sent from my (new) iPhone > > > On 12 Jul 2008, at 21:48, "Senaka Fernando" <[EMAIL PROTECTED]> wrote: > > 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 >>>>>> >>>>>> >>>>> >>>> >>>
