Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [stellation-res] Fix in progress: LogEntry timestamp string formats (#34180) 
I've just posted a patch to stellation.cli and stellation.scm.model.
(Attachment to #34180)

** It would be great if Jonathan or Mark could verify the fix. **

At 08:11 AM 3/9/2003, Jonathan Gossage wrote:

> -----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)
>

<snip>

> 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.
>


I basically agree with Jonathan that locale formatting is a presentation
issue.  In this case, I've also chosen to include a generic "friendly"
time string format for embedding into the log.xml file along, with the
epochMilliseconds string.  (The "friendly" property is "time"; the
epochMilliseconds property is "timestamp").
A client can easily apply locale-specific formatting,
by getting either a long epochMilliseconds value (LogEntry.getTimestamp())
or a transient Date value (LogEntry.getTime(), as before) and then
using DateFormat to construct the desired time-date string.
There is an extended comment at the top of LogEntry detailing other considerations; 
I should probably add the note about locale formatting.  It may be worth noting
that the class has been reworked a bit to use lazy on-demand attribute creation, and to use a single static Date instance for formatting rather than a per-instance Date object. As it stands, it's still necessary to load the entire log into memory before 
appending an entry; this was a performance bottleneck some time back and should
probably be addressed in future (perhaps by using SAX rather than DOM).

Regards,
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

Back to the top