harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: Time Zone Question
Date Thu, 17 Jul 2008 03:15:16 GMT
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
>

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