On Wed, 8 Jan 2003, Sean Schofield wrote:
> >Yup. Definitely _has_ to extend Format. Even if it isn't seen as a > >SimpleDateFormat option. > > > So are you saying it should extend Format? Why should this be required? > And if we do want to extend Format, what do you we do about the parsing > requirements. The original FastDateFormat supported formatting only (no > parsing from text to Date). We could take a stab at adding that part > but I'd probably need some help there... > If it ends with 'Format', then I think it's pretty commonly understood to be an extension of java.text.Format. Just as if it ended with Map, or Iterator. Something I do/aim-to-do with Format objects is to have a Formatter class which wraps a ClassMap of Class to Format. Then I'd say: formatter.format(date) and it would look up java.util.Date, see it maps to FastDateFormat and use that. Any reason why we can't just delegate the parse() method to the SimpleDateFormat? If we don't extend Format, I think it should be called FastDateFormatter. > - sean > > ps. Should we start using [lang][time] in the subject lines to spare > people the volume of emails dedicated to the time subpackage? Or is > there an exisiting commons-dev mailing list convention for this? It's not that noisy yet :) If it did get noisy, [and it would have to be a lot noisier] then I imagine we'd have to go for a Lang mailing list or something. Which would probably be a bad idea as the Commons community in general often have a lot to say on Lang. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
