ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan.Mate...@rzf.fin-nrw.de
Subject RE: Timestamp attribute processing
Date Tue, 02 Sep 2003 04:34:43 GMT
BTW, your first post was to the old adress "ant-dev@apache.org".
Maybe your adress book isnĀ“t uptodate :-)


Jan


> -----Original Message-----
> From: Steve Cohen [mailto:SCohen@sportvision.com]
> Sent: Tuesday, September 02, 2003 4:37 AM
> To: Ant Developers List
> Subject: RE: Timestamp attribute processing
> 
> 
> I've decided to do the following:
> I allow user to optionally specify a SimpleDateFormat String. 
>  If they don't do that, my routine will try by default 
> DateUtils.ISO8601_DATETIME_PATTERN and if that fails, then 
> DateUtils.ISO8601_DATE_PATTERN.  If a format is supplied and 
> fails or if one isn't supplied and neither of the defaults 
> work, I throw an exception.  I've put this logic into 
> StarTeamCheckout, because DateUtils seems to have a somewhat 
> different purpose (like getPhaseOfMoon()??? :-) ) and I'm not 
> sure my logic is generically applicable.  So I am using 
> DateUtils but not modifying it.  I could put 
> SimpleDateFormat.parse() inside a wrapper, but that seems pointless.
> 
> 
> -----Original Message-----
> From:	Antoine Levy-Lambert [mailto:antoine@antbuild.com]
> Sent:	Mon 9/1/2003 6:12 PM
> To:	Ant Developers List
> Cc:	
> Subject:	Re: Timestamp attribute processing
> Yes, if you think of a good generic routine to parse strings 
> into dates,
> then DateUtils should be the place for it.
> 
> Antoine
> ----- Original Message -----
> From: "Steve Cohen" <SCohen@sportvision.com>
> To: "Ant Developers List" <dev@ant.apache.org>
> Sent: Monday, September 01, 2003 10:27 PM
> Subject: RE: Timestamp attribute processing
> 
> 
> 
> Hmm, that's weaker than I would have expected.  If I'd like 
> something a
> little better, is your recommendation then to add to DateUtils?
> 
> The StarTeam API uses something they call an OLEDate, which 
> I'm sure has
> some sort of parse capability but if I rely on that then I 
> run the risk of
> being out of synch with the rest of Ant.
> 
> -----Original Message-----
> From: Antoine Levy-Lambert [mailto:antoine@antbuild.com]
> Sent: Mon 9/1/2003 3:15 PM
> To: Ant Developers List
> Cc:
> Subject: Re: Timestamp attribute processing
> - there is a date selector with a method 
> DateSelector#setDateTime which
> contains parsing code (with a hardcoded US locale, looks like 
> the europeans
> (continentals) are not allowed to enter DD-MM-YYYY dates, 
> MM-DD-YYYY is
> preferred.
> 
> - there is a DateUtils class in ant  It has methods to format 
> dates, but not
> to parse them. Parsing methods should be added there.
> 
> - the cvstagdiff task has attributes which are 
> date/timestamps, but the task
> does not parse these attributes itself, rather they are copied without
> parsing as command line arguments for the cvs executable.
> 
> - the tstamp task can create strings (properties) 
> representing dates, but
> does not have to parse the strings back
> 
> Cheers,
> 
> Antoine
> ----- Original Message -----
> From: "Steve Cohen" <SCohen@sportvision.com>
> To: <ant-dev@apache.org>
> Sent: Monday, September 01, 2003 9:58 PM
> Subject: Timestamp attribute processing
> 
> 
> There have been some requests to add functionality to the 
> stcheckout task
> (for StarTeam) to enable checkout by a timestamp.  It will 
> not be hard to do
> this, as the scenario is well-supported in the StarTeam API.
> 
> However, what about the Ant API?  Is there a standard way (and
> reusable/accessible code) for passing in timestamps as 
> attributes to a task?
> It seems like a bad idea for every task to roll its own date-parse
> processing.  Can someone point me at a better way to 
> implement it in ant?
> Ideally this would support at least yyyy-MM-dd, yyyy-MM-dd 
> hh:mm without
> making the user supply a date-format string.
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> 
> 
> 
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message