You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/09/11 10:51:11 UTC
Re: [lang] FastDateFormat year bug
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" <fl...@gmail.com>
> 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) <jc...@bear.com>
> 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
Re: Time bugs Was: [lang] FastDateFormat year bug
Posted by Henri Yandell <fl...@gmail.com>.
Actually, I retract this. If it switches to P'y'Y, then it won't print
out 2002 but 02 when it does large durations. I think the 'hack' of
using a DateFormat to format durations is stretched here.
So 2 problems now. Years are broke in ISO_EXTENDED and dates are broke
in FastDateFormat.
Hen
On Sun, 12 Sep 2004 00:40:51 -0400, Henri Yandell <fl...@gmail.com> wrote:
> 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'"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Time bugs Was: [lang] FastDateFormat year bug
Posted by Henri Yandell <fl...@gmail.com>.
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
<sc...@btopenworld.com> 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" <fl...@gmail.com>
> > 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) <jc...@bear.com>
> > 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