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...
On Tue, 7 Jan 2003, Stephen Colebourne wrote:
----- Original Message -----Yup. Definitely _has_ to extend Format. Even if it isn't seen as a
From: "Henri Yandell" <[EMAIL PROTECTED]>
On Tue, 7 Jan 2003, Sean Schofield wrote:Its not a SimpleDateFormat drop-in as it doesn't extend Format. It should do
1) I removed two of the overloaded getInstance() methods that tookIf there's no reason as to why they're a pain to keep in, would be nice to
DateFormatSymbols as arguments. SimpleDateFormat does allow a
DateFormat to be constructed using DateFormatSymbols but I thought for
now it might be nice to leave this out. It could be argued, however,
that we should include support for this, since some have described this
class as a thread-safe replacement for SimpleDateformat. (Actually the
changes related to this were commented-out for now so we can undo them
if people want.)
not get some javadoc-lawyer hitting us with the reason why FastDateFormat
isn't a SimpleDateFormat replacement.
(not the parsing, just the formatting part - throw
UnsupportedOperationException from the parsing)
SimpleDateFormat option.
- 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?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
