[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [stellation-res] Timestamp handling
|
Jonathan Gossage wrote:
There are a number of places where we are using the following sequence of
code that leads to problems and inefficiency.
Date t = // get from somewhere
attributes.put("time", t.toString());
.
.
.
.
Date date = null;
try {
date = DateFormat.getDateInstance().parse(attributes.get("time"));
}
catch (ParseException pe) {
logger.debug("Invalid date in attribute: " + attributes.get("time") + ",
using now as default");
date = new Date();
}
This code is failing everywhere sice DateFormat.parse() cannot handle the
output from Date.toString(). In addition it is very expensive in processing
and resultsa in losing information. I believe that we should use the Date
objects directly instead of the string representation, and when we need to
write externally (e.g. to XML files we should write the long integer
representation of the date.
I agree completely.
The whole time handling code was, frankly, a complete mess. I've been
working on cleaning it up, but there's still more to go.
The remaining problems that I know of (which, I think, is the case
you're pointing at - please correct me if I'm wrong) are cases where,
for some reason, the command-line code was
using a StringMap as a general map. StringMap is intended to be a
type-specific map
from strings to strings. It had evolved into a rather strange generic
string-to-object
map where the object value was stringified on insertion and parsed on
retrieval. I first
got rid of the type-specific methods in the StringMap. I now need to go
through
the uses of StringMap, and find all of the instances where it's really
not a stringmap.
I wasn't rushing on this, because as it stands, it's working on my linux
box, so I assumed
it was in a relatively stable state. If it's causing problems, I'll bump
it up and
take care of it ASAP.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx