harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Yu" <junjie0...@gmail.com>
Subject Re: Time Zone Question
Date Thu, 17 Jul 2008 07:05:05 GMT
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 <ndbeyer@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 <junjie0122@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 <ndbeyer@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 <junjie0122@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 <ndbeyer@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 <junjie0122@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 <senakafdo@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 <junjie0122@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 <senakafdo@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message