harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: Time Zone Question
Date Sun, 13 Jul 2008 18:02:11 GMT
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
>

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