You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Senaka Fernando <se...@gmail.com> on 2008/07/12 11:36:06 UTC
Time Zone Question
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
Re: Time Zone Question
Posted by Tharindu Mathew <mc...@gmail.com>.
I seemed to have overlooked the ONE_HOUR constant. I assumed that offset
would be in hours not milliseconds.
Introducing a HALF_HOUR constant would solve the problem as Nathan pointed
out.
Regards,
Tharindu
On Sun, Jul 13, 2008 at 12:27 AM, Nathan Beyer <nd...@apache.org> 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 <se...@gmail.com>
> 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 <mc...@gmail.com>
> > 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 <se...@gmail.com>
> > > 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
> > > >
> > >
> >
>
Re: Time Zone Question
Posted by Senaka Fernando <se...@gmail.com>.
The worst case would be when we have to make 5.75 which will require all
three constants. But, given the benefits, it seems desirable.
Regards,
Senaka
On Sun, Jul 13, 2008 at 10:52 PM, Nathan Beyer <nd...@apache.org> wrote:
> 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 <al...@gmail.com>
> 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" <se...@gmail.com> 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 <nd...@apache.org>
> >> 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 <se...@gmail.com>
> >>> 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 <mccloud35@gmail.com
> >
> >>>> 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 <
> senakafdo@gmail.com>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
>
Re: Time Zone Question
Posted by Nathan Beyer <nd...@apache.org>.
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 <al...@gmail.com>
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" <se...@gmail.com> 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 <nd...@apache.org>
>> 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 <se...@gmail.com>
>>> 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 <mc...@gmail.com>
>>>> 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 <se...@gmail.com>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
Re: Time Zone Question
Posted by Alex Blewitt <al...@gmail.com>.
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" <se...@gmail.com> 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 <nd...@apache.org>
> 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
>> <se...@gmail.com>
>> 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 <mccloud35@gmail.com
>>> >
>>> 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 <senakafdo@gmail.com
>>>> >
>>>> 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
>>>>>
>>>>
>>>
>>
Re: Time Zone Question
Posted by Jim Yu <ju...@gmail.com>.
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 <nd...@apache.org>:
> 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 <ju...@gmail.com> 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 <nd...@apache.org>:
> >
> > > 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 <ju...@gmail.com>
> 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 <nd...@apache.org>:
> > > >
> > > > > 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 <ju...@gmail.com>
> > 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 <se...@gmail.com>:
> > > > > >
> > > > > > > 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 <ju...@gmail.com>
> > > > 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 <se...@gmail.com>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > ndbeyer@apache.org
> > > > > >
> > > > > > > > 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 <
> > > > > > > senakafdo@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > mccloud35@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > > senakafdo@gmail.com>
> > > > > > > > > > > > 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
Re: Time Zone Question
Posted by Nathan Beyer <nd...@apache.org>.
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 <ju...@gmail.com> 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 <nd...@apache.org>:
>
> > 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 <ju...@gmail.com> 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 <nd...@apache.org>:
> > >
> > > > 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 <ju...@gmail.com>
> 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 <se...@gmail.com>:
> > > > >
> > > > > > 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 <ju...@gmail.com>
> > > 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 <se...@gmail.com>:
> > > > > > >
> > > > > > > > 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 <
> > > ndbeyer@apache.org
> > > > >
> > > > > > > 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 <
> > > > > > senakafdo@gmail.com>
> > > > > > > > > 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 <
> > > > > > > mccloud35@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > senakafdo@gmail.com>
> > > > > > > > > > > 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
>
Re: Time Zone Question
Posted by Jim Yu <ju...@gmail.com>.
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 <nd...@apache.org>:
> 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 <ju...@gmail.com> 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 <nd...@apache.org>:
> >
> > > 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> > > >
> > > > > 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 <ju...@gmail.com>
> > 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 <se...@gmail.com>:
> > > > > >
> > > > > > > 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 <
> > ndbeyer@apache.org
> > > >
> > > > > > 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 <
> > > > > senakafdo@gmail.com>
> > > > > > > > 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 <
> > > > > > mccloud35@gmail.com>
> > > > > > > > > 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 <
> > > > > > > senakafdo@gmail.com>
> > > > > > > > > > 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
Re: Time Zone Question
Posted by Nathan Beyer <nd...@apache.org>.
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 <ju...@gmail.com> 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 <nd...@apache.org>:
>
> > 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> > >
> > > > 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 <ju...@gmail.com>
> 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 <se...@gmail.com>:
> > > > >
> > > > > > 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 <
> ndbeyer@apache.org
> > >
> > > > > 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 <
> > > > senakafdo@gmail.com>
> > > > > > > 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 <
> > > > > mccloud35@gmail.com>
> > > > > > > > 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 <
> > > > > > senakafdo@gmail.com>
> > > > > > > > > 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
>
Re: Time Zone Question
Posted by Jim Yu <ju...@gmail.com>.
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 <nd...@apache.org>:
> 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> >
> > > 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> > > >
> > > > > 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 <ndbeyer@apache.org
> >
> > > > 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 <
> > > senakafdo@gmail.com>
> > > > > > 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 <
> > > > mccloud35@gmail.com>
> > > > > > > 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 <
> > > > > senakafdo@gmail.com>
> > > > > > > > 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
Re: Time Zone Question
Posted by Tharindu Mathew <mc...@gmail.com>.
I think it's more consistent if we use a HALF_HOUR, THREE_QUARTER_HOUR,
QUARTER_HOUR constants and add all the timezones not currently available.
WIthout letting differnt timezones be instantiated differntly, try to
maintain a consistent way.
statements like ONE_HOUR + 1800000 should be taken out and replaced with
constants to make the code more consistent
Can't we go for an all ICU Time zone approach? I found this bug because the
Asia/Colombo time zone was stated explicitly. As ICU is updated, any future
changes will be reflected.
Regards,
Tharindu
On Tue, Jul 15, 2008 at 5:25 AM, Nathan Beyer <nd...@apache.org> wrote:
> 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> >
> > > 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> > > >
> > > > > 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 <ndbeyer@apache.org
> >
> > > > 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 <
> > > senakafdo@gmail.com>
> > > > > > 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 <
> > > > mccloud35@gmail.com>
> > > > > > > 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 <
> > > > > senakafdo@gmail.com>
> > > > > > > > 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
> >
>
Re: Time Zone Question
Posted by Nathan Beyer <nd...@apache.org>.
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 <ju...@gmail.com> 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 <se...@gmail.com>:
>
> > 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> > >
> > > > 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 <nd...@apache.org>
> > > 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 <
> > senakafdo@gmail.com>
> > > > > 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 <
> > > mccloud35@gmail.com>
> > > > > > 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 <
> > > > senakafdo@gmail.com>
> > > > > > > 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
>
Re: Time Zone Question
Posted by Jim Yu <ju...@gmail.com>.
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 <se...@gmail.com>:
> 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 <ju...@gmail.com> 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 <se...@gmail.com>:
> >
> > > 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 <nd...@apache.org>
> > 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 <
> senakafdo@gmail.com>
> > > > 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 <
> > mccloud35@gmail.com>
> > > > > 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 <
> > > senakafdo@gmail.com>
> > > > > > 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
Re: Time Zone Question
Posted by Senaka Fernando <se...@gmail.com>.
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 <ju...@gmail.com> 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 <se...@gmail.com>:
>
> > 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 <nd...@apache.org>
> 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 <se...@gmail.com>
> > > 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 <
> mccloud35@gmail.com>
> > > > 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 <
> > senakafdo@gmail.com>
> > > > > 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
>
Re: Time Zone Question
Posted by Jim Yu <ju...@gmail.com>.
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 <se...@gmail.com>:
> 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 <nd...@apache.org> 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 <se...@gmail.com>
> > 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 <mc...@gmail.com>
> > > 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 <
> senakafdo@gmail.com>
> > > > 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
Re: Time Zone Question
Posted by Senaka Fernando <se...@gmail.com>.
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 <nd...@apache.org> 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 <se...@gmail.com>
> 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 <mc...@gmail.com>
> > 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 <se...@gmail.com>
> > > 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
> > > >
> > >
> >
>
Re: Time Zone Question
Posted by Nathan Beyer <nd...@apache.org>.
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 <se...@gmail.com>
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 <mc...@gmail.com>
> 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 <se...@gmail.com>
> > 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
> > >
> >
>
Re: Time Zone Question
Posted by Senaka Fernando <se...@gmail.com>.
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 <mc...@gmail.com>
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 <se...@gmail.com>
> 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
> >
>
Re: Time Zone Question
Posted by Tharindu Mathew <mc...@gmail.com>.
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 <se...@gmail.com>
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
>