Scott, Your patch and Rob's path overlapped the most. I'll address Thomas' in a separate email.
I've committed Rob's patch for now. I preferred the nested element approach to defining the formats. It is nicely explicit and I think it may be best to leave the current, implicitly named values with their fixed formats. What do you think? Do you think think your "gold plating" is also required? If you do, let me know and I can add it in the context of Rob's approach or you can send me an updated patch. Cheers Conor ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 29, 2000 2:25 PM Subject: Re: TStamp - custom formats > This is the third Tstamp patch that's been submitted. (Mine being > the second) What will actually get committed? > > Scott > > On Thu, 28 Dec 2000, Rob Oxspring wrote: > > > I've just modified my copy of the Tstamp task, and thought others may want to use/commit it. It adds the capability of creating properties with any format that the SimpleDateFormat class can handle. This means that we are no longer restricted to the US style (eg UK) and can add other stuff such as zimetone and era (should anybody have a need!). The default behaviour is unchanged, and the only downside is that it sets properties just as the rest of Tstamp does and does not tread carefully as the property task does - is this a problem?. The extended syntax is: > > > > <tstamp> > > <property name="TODAY_UK" pattern="d MMMM yyyy"> > > </tstamp> > > > > This will add a property TODAY_UK to the project with the value in the format: "28 December 2000" > > > > Hope its useful > > > > Rob > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
