[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Timestamp handling
|
At 09:01 PM 3/14/2003, Mark C. Chu-Carroll wrote:
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.
I also agree.
Everything Jonathan said is directly applicable to the mess I found in the
LogEntry code. In this case (since LogEntries are pretty-directly persisted
to XML), I chose the following approach:
* For the internal LogEntry timestamp format, use a long epoch-milliseconds
value. (I considered Date, but was a bit concerned over potential footprint
issues {As a first-class object with several instance variables, a Date is
significantly larger than a long integer, and the entire Log is loaded into
memory for processing}. I may have been overreacting, of course.)
* The LogEntry API provides time value getters and setters for Date, but
also for long integers and strings.
* String attribute values are created lazily from the long integer instance
variable, to minimize StringMap time/space overhead. No parsing or
formatting occcurs unless an attribute is explicitly requested (or input)
via one path or another.
Now, this approach may or may not be suitable for other places where time
values are used. For one thing, most code should _never_ deal with
string-format time values. (UI and persistence code are the only exceptions
that come to mind.) For another, it may be perfectly reasonable to use Dates
rather than long integers in the bulk of cases.
It may be worth looking at the revised LogEntry code to see if the approach
I used is appropriate elsewhere (particularly since managing multiple time
representations has some subtle and potentially buggy aspects, and I believe
the new LogEntry code handles them reasonably well). Conversely, if it
seems another approach is more generally useful, we may want to revise the
LogEntry code again in order to conform to general time value practices
throughout Stellation.
Personally, I think epoch-milliseconds are pretty useful. They're dirt
simple to store, manipulate, compare and string-process, and they're
relatively immune to wong-time-zone errors (assuming the client has the local
time zone set correctly when the epoch-miliseconds value is generated).
Date.getTime and Date.setTime are very low-overhead methods, and the current
LogEntry approach attempts to minimize overhead as well (a single Date and
DateFormat instances are configured for the current locale and desired
formatting, and then cached; all subsequent processing reuses the cached
instances, avoiding object creation/destruction overhead).
- Jim
--------------------------------------------------------------------
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
