You can see the patch I submitted here: http://issues.apache.org/bugzilla/show_bug.cgi?id=20578
-----Original Message----- From: Ken Gentle [mailto:[EMAIL PROTECTED] 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 >my task to accept either of the ISO8601 formats in DateUtils >(yyyy-MM-ddThh:mm:ss or yyyy-MM-dd) if no format is specified by the >user, OR if the user specifies a time format in the parameters to the ><stcheckout> task, parse only against that single format (and not the >defaults). While that may fit your definition of a slippery slope, I >really don't think so since the only defaults are standards and >anything non-standard must be specified by the user in the same >task-invocation as the data being passed to the task. And the "nested >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 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 just throwing their favorite format in the list. I think we're in violent agreement... ;^) >-----Original Message----- >From: Ken Gentle [mailto:[EMAIL PROTECTED] >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 > >>something a little better, is your recommendation then to add to > >>DateUtils? > > > >I guess it is time for a date type. I imagine taking > >java.util.Calendar > > >as > >a param would be a nice way to map it (or Date, though that one's > >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 >processing > >arbitrary date formats. I don't believe that the date parsing is >consistent across ant tasks now, and tasks like CVSTAGDIFF don't parse >their date parameters at all, but pass them through to the underlying >app. > >As date formats are different across locales, and date strings can be >very ambiguous (MM-DD-YYYY vs DD-MM-YYYY for example will both "match" >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 >working with now -- there are a list of US specific formats that are >each tried against the input string until one matches. This was >originally coded as >the nested exception handler from hell... > >Anyway, I'd suggest be very cautious about introducing general date >processing in ant that would allow arbitrary date formats, as opposed >to > >one or two formats per locale, or a single ISO style format >"yyyy-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the >spec in front of me). > > Ken > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
