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
<[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > 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) <[EMAIL PROTECTED]>
> > Date: Fri, 10 Sep 2004 14:22:44 -0400
> > Subject: FastDateFormat year bug
> > To: [EMAIL PROTECTED]
> >
> >
> >
> >
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
>
>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
