Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Timestamp attribute processing
Date: Wed, 3 Sep 2003 08:50:11 -0500
Message-ID: <D466FBEAA19E7E408BE3FAAC6EEB5676038A904A@utah.ignitemedia.com>
Thread-Topic: Timestamp attribute processing
thread-index: AcNxkL3ANJSkM4dNS22HxDvh9R2SagAkVL/g
From: "Steve Cohen" <SCohen@sportvision.com>
To: "Ant Developers List" <dev@ant.apache.org>

You can see the patch I submitted here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=3D20578

-----Original Message-----
From: Ken Gentle [mailto:j.kenneth.gentle@acm.org]=20
Sent: Tuesday, September 02, 2003 3:27 PM
To: Ant Developers List
Subject: RE: Timestamp attribute processing


At 02:52 PM 9/2/2003, you wrote:
>I appreciate what you are saying.
>
>What I did so far, and none of it has been submitted yet, was to code=20
>my task to accept either of the ISO8601 formats in DateUtils=20
>(yyyy-MM-ddThh:mm:ss or yyyy-MM-dd) if no format is specified by the=20
>user, OR if the user specifies a time format in the parameters to the=20
><stcheckout> task, parse only against that single format (and not the=20
>defaults).  While that may fit your definition of a slippery slope, I=20
>really don't think so since the only defaults are standards and=20
>anything non-standard must be specified by the user in the same=20
>task-invocation as the data being passed to the task. And the "nested=20
>exception handler from hell" is only two levels deep.

Sorry, I must not have been following this thread as well as I thought.

You're solution there is very similar to what I'd planned to do (but=20
haven't gotten to) for the CvsChangeLog task.

Granted, the exception handler is only two levels deep, but it will take

some discipline, education and monitoring to prevent later developers
from=20
just throwing their favorite format in the list.

I think we're in violent agreement... ;^)


>-----Original Message-----
>From: Ken Gentle [mailto:j.kenneth.gentle@acm.org]
>Sent: Tuesday, September 02, 2003 1:35 PM
>To: Ant Developers List
>Subject: Re: Timestamp attribute processing
>
>
>At 12:56 PM 9/2/2003, you wrote:
> >Steve Cohen wrote:
> >>Hmm, that's weaker than I would have expected.  If I'd like=20
> >>something a little better, is your recommendation then to add to=20
> >>DateUtils?
> >
> >I guess it is time for a date type. I imagine taking=20
> >java.util.Calendar
>
> >as
> >a param would be a nice way to map it (or Date, though that one's=20
> >lack
>of
> >timezones is an eternal source of trouble in the SOAP world)
>
>SOAP and everywhere an application may span timezones.
>
>This sounds like the first step down a very slippery slope of=20
>processing
>
>arbitrary date formats.  I don't believe that the date parsing is=20
>consistent across ant tasks now, and tasks like CVSTAGDIFF don't parse=20
>their date parameters at all, but pass them through to the underlying=20
>app.
>
>As date formats are different across locales, and date strings can be=20
>very ambiguous (MM-DD-YYYY vs DD-MM-YYYY for example will both "match"=20
>the input
>string '12-12-2000' and there is no way to "dis-ambiguate" them without
>some other input.
>
>This is a sore point with me because for the mess in the system I'm=20
>working with now -- there are a list of US specific formats that are=20
>each tried against the input string until one matches.  This was=20
>originally coded as
>the nested exception handler from hell...
>
>Anyway, I'd suggest be very cautious about introducing general date=20
>processing in ant that would allow arbitrary date formats, as opposed=20
>to
>
>one or two formats per locale, or a single ISO style format=20
>"yyyy-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the=20
>spec in front of me).
>
>          Ken
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org