commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: Time bugs Was: [lang] FastDateFormat year bug
Date Sun, 26 Sep 2004 04:31:24 GMT
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)
<jchua@bear.com> 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:flamefew@gmail.com]
> 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 <flamefew@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
> 
> 
> 
> ***********************************************************************
> 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


Mime
View raw message