ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject [PATCH] Unified date / locale parsing - was Re: Selectors documentation and a Reference bug fix
Date Mon, 13 May 2002 15:08:06 GMT
The main aim of these patches is to be a little more consistent with the
date handling in existing tasks (and allow other tasks to easily join the
party) while allowing a little more flexibility for those of us that don't
get on with US style date formats.

The first patch adds date and locale parsing methods to the DateUtils class
along with testcases.  This is mainly stolen from the <tstamp/> code and is
probably uncontroversial.  The method of use being:

DateUtils.parseDate(dateAsString,formatPattern,localeAsString);

the pattern and locale parameters can be supplied as null and default to
SHORT and US respectively.  Thus having the same default as the touch and
dateselector classes at present.

The second patch is probably more controversial as it affects the xml ui a
little, it changes tstamp to use the central locale parsing, and applies the
whole date parsing within the dateselector and touch tasks.  Both
DateSelector and Touch now have optional attributes pattern="" and locale=""
allowing custom formats to be used, mirroring tstamp's format elements.
Also both now throw exceptions if both milliseconds AND datetime are
supplied (this looks to be an oversight in one copied into the other),
arguably it should check that they are different before complaining but I
see no point in allowing both to be set.

Now, here's where I push my luck: I would really like these to go into Ant
1.5.  The patch cropped up because I didn't like the default format of the
dateselector code and I regard it as a unnecessary limitation on the user
interface side of things... calling it a bug and therefore patching it into
1.5 is a bit rich though.

So I guess its up to the committers, Magesh in particular, to decide whether
it can sneak onto the 1.5 branch.  Doc patches will follow if the patches
are accepted.

Rob


----- Original Message -----
From: "Rob Oxspring" <roxspring@imapmail.org>
To: "'Ant Developers List'" <ant-dev@jakarta.apache.org>
Sent: Friday, May 10, 2002 2:38 AM
Subject: RE: Selectors documentation and a Reference bug fix


>
>
> > -----Original Message-----
> > From: Bruce Atherton [mailto:bruce@callenish.com]
> > Sent: 10 May 2002 01:13
> > To: Ant Developers List
> > Subject: Re: Selectors documentation and a Reference bug fix
> >
> >
> > At 06:25 PM 5/9/2002 +0100, Rob Oxspring wrote:
> > >I thought this would be the reply - I really think that ant is
> > >generally very good at being verbose and descriptive in its
> > syntax and
> > >it would be a shame to let this slip by.  Taking another tack: if we
> > >don't want to use equal as the default (being uncommon is a fair
> > >argument) then why choose "less" over "more"? These strike me as
> > >equally common and so we'd only be shortening the typing for
> > half the
> > >cases.
> >
> > Sorry to be so predictable. :-)
>
> :)
>
> >
> > Why choose "less" over "more" in <size>? Well, I did that in
> > order to stay
> > orthogonal to <date>, which defaults to "before" rather than
> > "after".
>
> I absolutely agree on the consistency front.
>
> > And I
> > chose that because dates on files tend to be more in the past
> > than in the
> > future.
>
> The dates of the files involved are extremely likely to be in the past,
> but not necessarily less than the reference date which is also likely to
> be sometime in the past.
>
> > They are still completely arbitrary, though, I agree.
> >
> > Yes, it only shortens half the typing, but I thought that
> > might be better
> > than nothing at all.
> >
> >
> > >The bottom line is that I think that people maintaining the code /
> > >script being able to quickly understand it is far more
> > important than
> > >the coder typing less.  Maybe this is a case where no
> > default should be
> > >given?
> >
> > Converting to "equal" would be tantamount to no default since
> > its use is
> > rare, so I see no advantage to requiring the attribute.
> >
> I agree - was just thinking out loud really.
>
> > Since I have only a mild preference and you and Dominique
> > appear to have a
> > strong one, Ill change the default to "equals" if no one else has an
> > opinion to the contrary.
>
> Thanks!
>
> Rob
>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:ant-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>
>

Mime
View raw message