RE: [stellation-res] Timestamp handling

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> IBM Research
> Sent: Saturday, March 15, 2003 12:28 PM
> To: stellation-res@xxxxxxxxxxxxxxx
> Subject: 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
>
I agree tht we should use epoch milliseconds as the format to persist
timestamps in and should consider only materializing them as Date objects
when those methods are actually needed.

Regards

Jonathan