[stellation-res] Fix in progress: LogEntry timestamp string formats (#34

[Jim Wright - IBM Research <jwright@xxxxxxxxxxxxxx>]

I am currently working on a fix for a LogEntry timestamp problem which
surfaced during work on the Eclipse client.  This problem is also likely to
surface during certain command-line logfile operations.  Bugzilla #34180 has
been entered to track this issue.  Details follow.

Recent changes (#32077) have caused inconsistencies in the time string
format used by LogEntry Class org.eclipse.stellation.cli.data.LogEntry.  The
format used is sometimes DateFormat.DEFAULT (== DateFormat.MEDIUM), but
sometimes DateFormat.FULL.  Furthermore, this string is locale-sensitive,
which could potentially cause problems as This can cause roblems while
loading a LogEntry from the log, using DateFormat.parse(String), which is
rather fragile. The current version throws a ParseException (which breaks
the Stellation CM InfoView Status display).

I have prototyped a fix which enforces consistent, locale-independent usage
throughout LogEntry.  As prototyped, the fixed timestring format is
"Numeric-day Month-name 4-digit-year, hours:minutes:seconds.milliseconds
TimeZone", where hours uses 0...23 and am/pm is not needed.

This has fixed the original problem re: breaking the InfoView Status
display. However, using this extended, verbose time string is potentially
problematic (it makes locale-specific time formatting more difficult, and
assumes the timestamp format will not change again in future).

Use of epoch-milliseconds timestamps for LogEntry persistency seems like a
much better fix (and is also consistent with the #32077 fix for repository
timestamps).  I am starting work on this, and will post a patch when complete.

Note that the LogEntry API is changing slightly.  Date getTime() and void
setTime(Date) will be retained.

String getTimeAsString(), String getDateAsString() will be added. These will
use a fixed locale-independent format as described above. Other formats are
available by retrieving the Date using getTime() and formatting a string
value. as desired.

long getTimestamp() and void setTimestamp(long epochMilliseconds) will be
added. All persistency operations should use the Timestamp methods.

The (unused) LogEntry "date" attribute is removed.  The "time" attribute is
retained, but not used for setting Date values when the LogEntry is
reloaded; this should eliminate ParseException errors (at least within the
LogEntry code). A "timestamp" attribute is added, for persistency.

Comments welcome --

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