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 Wed, 16 Jul 2008 04:23:21 GMT
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

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