RE: [stellation-res] Timestamp handling

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> Chu-Carroll
> Sent: Friday, March 14, 2003 9:01 PM
> To: stellation-res@xxxxxxxxxxxxxxx
> Subject: 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

I think you are getting into JVM specific behaviour here. I am using the Sun
1.4.1-02 JVM since I have had nothing but problems with the IBM JVM's under
Windows. The underlying problem that we are seeing here is that there is
nothing in the contracts for the Date.toString() method and the
DateFormat.parse() method that says that the output of the first method is
guaranteed to be parsable by the second method. It seems that the IBM JVM on
Linux lets you get away with it while the Sun JVM on Windows does not. The
problem may become even worse in a client/server environment where different
JVM's may be used on the client and the server.

The specific area that needs to be addressed is the "time" attributes for
the CompoundArtifact, TextArtifact, DataAtrifact and LinkArtifact. On
Windows we are getting ParseExceptions all over the place which is resulting
in the original "time" attributes becoming lost. These all use the
DateFormat.parse() method to recover a time stamp from a string in a string
representation of the "time" attribute. In all cases, when the attribute is
created, it is created with a Date.toString() method.

I think this is a priority 1 item because it is causing critical data to be
lost but it is also the tip of the iceberg since I think that the whole
method of handling attributes for the artifacts is brittle and may cause us
problems down the road.

Regards

Jonathan