Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 38418 invoked from network); 12 Sep 2004 04:41:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 12 Sep 2004 04:41:09 -0000 Received: (qmail 14868 invoked by uid 500); 12 Sep 2004 04:41:04 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 14778 invoked by uid 500); 12 Sep 2004 04:41:03 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 14764 invoked by uid 99); 12 Sep 2004 04:41:03 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of flamefew@gmail.com designates 64.233.170.207 as permitted sender) Received: from [64.233.170.207] (HELO mproxy.gmail.com) (64.233.170.207) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 11 Sep 2004 21:41:00 -0700 Received: by mproxy.gmail.com with SMTP id 78so58250rnk for ; Sat, 11 Sep 2004 21:40:51 -0700 (PDT) Received: by 10.38.171.26 with SMTP id t26mr522926rne; Sat, 11 Sep 2004 21:40:51 -0700 (PDT) Received: by 10.38.164.15 with HTTP; Sat, 11 Sep 2004 21:40:51 -0700 (PDT) Message-ID: <31cc373604091121407cf7a54f@mail.gmail.com> Date: Sun, 12 Sep 2004 00:40:51 -0400 From: Henri Yandell Reply-To: Henri Yandell To: Stephen Colebourne Subject: Time bugs Was: [lang] FastDateFormat year bug Cc: Jakarta Commons Developers List In-Reply-To: <002b01c497dc$7d038b00$12059b51@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7AFC1B69BB12A4449A500E575E6D6B1302555BBF@whexchmb10.bsna.bsroot.bear.com> <31cc3736040910232617346a91@mail.gmail.com> <002b01c497dc$7d038b00$12059b51@oemcomputer> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Some additional issues to this: Jerson's fix does fix the bug he mentions, though another test fails in DurationFormatUtils; testISODurationFormat: // test fixture from example in http://www.w3.org/TR/xmlschema-2/#duration cal.set(1, 1, 3, 10, 30, 0); cal.set(Calendar.MILLISECOND, 0); text = DurationFormatUtils.ISO_EXTENDED_FORMAT.format(cal); assertEquals("P1Y2M3DT10H30M0.0S", text); This is, I believe, a bug in our pattern: ISO_EXTENDED_FORMAT_PATTERN = "'P'yyyy'Y'M'M'd'DT'H'H'm'M's.S'S'" should be: ISO_EXTENDED_FORMAT_PATTERN = "'P'y'Y'M'M'd'DT'H'H'm'M's.S'S'" Additionally, there seem to be some big problems in FastDateFormat in the date field. These are regardless of Jerson's fix, though I include it in the output: calendar.set(1,2,2) formats as 0001/03/61 calendar.set(999,11,30) formats as 0999/12/364 calendar.set(999,11,31) formats as 0999/12/365 calendar.set(2004,11,31) formats as 2004/12/366 Possibly I'm missing something important with the class, but it seems pretty damning. Hen On Sat, 11 Sep 2004 09:51:11 +0100, Stephen Colebourne wrote: > Certainly, if you've asked for yyyy then you should get a four digit year. > If the patch fixes this then great. > Stephen > > > > ----- Original Message ----- > From: "Henri Yandell" > > Sounds find to me. If no one says anything, I'll go ahead and put your > > fix in (with a unit test, unless you've a patch for that) over the > > weekend. > > > > Hen > > > > ----- Original Message ----- > > From: Chua, Jerson (Exchange) > > Date: Fri, 10 Sep 2004 14:22:44 -0400 > > Subject: FastDateFormat year bug > > To: commons-dev@jakarta.apache.org > > > > > > > > > > Hi to all, > > > > > > > > I used FastDateFormat to convert a date object to string using this > > pattern yyyy-MM-dd. > > > > No zeros are padded if I my year is 0001. > > > > > > > > I'm getting 1-01-01. > > > > > > > > After looking through the code, I replaced line 498 > > > > > > > > rule = UnpaddedNumberField.INSTANCE_YEAR; > > > > > > > > to > > > > > > > > rule = selectNumberRule(Calendar.YEAR, tokenLen); > > > > > > > > And it fixed the problem. > > > > > > > > Is the current behavior a feature (by design) or a bug? If it's a bug, > > can we put my change in? > > > > > > > > Thanks. > > > > > > > > Jerson > > > > > > > > > > > > > > > > > > *********************************************************************** > > Bear Stearns is not responsible for any recommendation, solicitation, > > offer or agreement or any information about any transaction, customer > > account or account activity contained in this communication. > > *********************************************************************** > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org