From dev-return-34610-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Wed Jul 16 01:50:27 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 52690 invoked from network); 16 Jul 2008 01:50:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Jul 2008 01:50:26 -0000 Received: (qmail 14070 invoked by uid 500); 16 Jul 2008 01:50:25 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 14043 invoked by uid 500); 16 Jul 2008 01:50:25 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 14032 invoked by uid 99); 16 Jul 2008 01:50:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jul 2008 18:50:25 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nbeyer@gmail.com designates 66.249.92.168 as permitted sender) Received: from [66.249.92.168] (HELO ug-out-1314.google.com) (66.249.92.168) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jul 2008 01:49:32 +0000 Received: by ug-out-1314.google.com with SMTP id t30so554930ugc.3 for ; Tue, 15 Jul 2008 18:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=jX1i1tDOy4VqHBekoRRLBuXkxpQqVHIx60uUH8MXYpg=; b=L4fcw2FUE9z1gp0Y0gi2YjOTJ2nd2/4kIC73K4RcBDFbWR96js+gwn71j1ZKjApheu B41oaxfNXEeVOpnSzF2eOVwCwvLTMn+LHKcuVoowRIe6jsR4cX0Ef2cNPCtC/Zlf++zr FusxpZ+Kh5l6N3J/95db4d0mSOcSD+a48x8Cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=nnipGgw+OLif8eRNMGBav7AZ72XhBSs0Ez4mT84u96ir6p2/P5qTLuXz6gvbNXIWmi 1YrO6gAJsDjg8kNagR9ztLC++nfwEQRQGLfPLh8Sy9JG23P8YlRswh2EsuLKEVcEiixh 6obeYGzXDsZyqG6HG7kFLQKhqVTsbPsP4cXrE= Received: by 10.125.125.6 with SMTP id c6mr3573519mkn.108.1216172994216; Tue, 15 Jul 2008 18:49:54 -0700 (PDT) Received: by 10.125.38.19 with HTTP; Tue, 15 Jul 2008 18:49:54 -0700 (PDT) Message-ID: <3b3f27c60807151849w12064791je1ad542c2ba0655@mail.gmail.com> Date: Tue, 15 Jul 2008 20:49:54 -0500 From: "Nathan Beyer" Sender: nbeyer@gmail.com To: dev@harmony.apache.org Subject: Re: Time Zone Question In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9103_29275066.1216172994189" References: <8812c4670807120236vf4b709aq1fd432fa0d7480f5@mail.gmail.com> <61d2e9b20807120434n1238f2bdx384ab46c4d428378@mail.gmail.com> <8812c4670807120628h228d4e09n23819885fff8d902@mail.gmail.com> <3b3f27c60807121157g1c2dd1efm8a43c05b14df3c89@mail.gmail.com> <8812c4670807121348y235f25e6r2401137fd03e0a33@mail.gmail.com> <8812c4670807131102m59d36233r454bd9bbce7fe9ab@mail.gmail.com> <3b3f27c60807141655j309e73eo6a61b2cc24d10b80@mail.gmail.com> X-Google-Sender-Auth: 963e92bb4fcd6577 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_9103_29275066.1216172994189 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 : > > > 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 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 : > > > > > > > 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 > 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 : > > > > > > > > > > > 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 > ------=_Part_9103_29275066.1216172994189--