Someone was smart and wrote a test to stop us doing this :)
It breaks the compatiblity with SimpleDateFormat.
I still think the real problem here is that we're trying to use a
DateFormat to represent a Duration, and DateFormat's lack the concept
of "ignore leading 0's".
Instead I've added a boolean padWithZeroes parameter to the format
method. So the broken test code changes from:
//text = DurationFormatUtils.ISO_EXTENDED_FORMAT.format(cal);
to
text = DurationFormatUtils.format(cal.getTime().getTime(),
DurationFormatUtils.ISO_EXTENDED_FORMAT_PATTERN, false);
Ugly, but at least it's now using a duration.
It also changes the date you pass in. The former didn't work on
milliseconds but had a time of 1 AD. The latter switches to use
milliseconds.
There are still a few problems in here. What used to, with FastDateFormat, be:
P1Y2M3DT10H30M0.0S
is now:
P1Y1M3DT3H30M0.0S
Now, the 10H to 3H difference is probably due to my weakly defined
YEAR/MONTH values.
The 2M to 1M is interesting. One month is the correct answer to my
mind, but it used to think it was 2 months. Looks like this is
actually a bug that's been fixed, so that's a plus.
Lastly, I'd like to go ahead and remove the
DurationFormatUtils.ISO_EXTENDED_FORMAT variable. The PATTERN would
probably be renamed to use this more concise name. It has a plus-point
that it handles years/months better, though still fails to work leaps
out correctly. It's weird to use as you have to use dates in the
mid-roman era.
Hen
On Mon, 13 Sep 2004 11:15:14 -0400, Chua, Jerson (Exchange)
<[EMAIL PROTECTED]> wrote:
> Hen,
>
> Try this one out.
>
> Update the code in case 'y' into this
>
> if (tokenLen == 2) {
> rule = TwoDigitYearField.INSTANCE;
> } else {
> rule = selectNumberRule(Calendar.YEAR, tokenLen);
>
>
> }
>
> -----Original Message-----
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 12, 2004 12:48 AM
> To: Jakarta Commons Developers List
> Subject: Re: Time bugs Was: [lang] FastDateFormat year bug
>
> 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 <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ***********************************************************************
> 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]
