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 Tue, 15 Jul 2008 04:25:00 GMT
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

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