RE: [stellation-res] Fix in progress: LogEntry timestamp string formats

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> IBM Research
> Sent: Friday, March 07, 2003 11:48 PM
> To: stellation-res@xxxxxxxxxxxxxxx
> Subject: [stellation-res] Fix in progress: LogEntry timestamp string
> formats (#34180)
>
>
> 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 problems 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.

I agree. This is a much more robust way of persisting date/time data. I
believe that locale formatting issues should be handled at presentation
time.
>
> 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
>

Regards

Jonathan