jtu...@objektfabrik.de
unread,Nov 14, 2012, 5:25:31 AM11/14/12Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to va-sma...@googlegroups.com
Hi there,
In the process of porting STON to VAST, I stumbled upon a problem in AbtTimestamp>>abtAsDateAndTime
abtAsDateAndTime
"Answer the receiver as an object which responds to the Date protocol."
^DateAndTime year: self date year
month: self date monthIndex
day: self date dayOfMonth
hour: self time hours
minute: self time minutes
second: self time seconds
The problem here is that the Timestamp's uSecs are not transferred. Sure, DateAndTime only has a resolution of milliseconds, but most AbtTimestamps also only have milliseconds even though it holds uSecs. I can't remember seeing an AbtTimestamp produced in VAST that had more that three non-zero digits in its uSecs.
So there probably is no mathematically correct way to convert an AbtTimestamp to a DateAndTime, but the loss if a few hundred milliseconds is not really a good thing as well.
Why do I need that? Because I firts thought it would be best if I use DateAndTime to write and read TimeStamps from STON files. STON is based on JSON and therefor uses the same format for expressing timestamps and DateAndTime, including the offset (whcih is not present in AbtTimestamp). Unfortunately, this doesn't fully work due to the above-mentioned problem. If I loose milliseconds, I cannot use STON as a data export format that accurately stores timestamps. This still holds true if I lose up to 999 nanoseconds, but it makes things at least a bit more accurate in the light of the fact that VAST-generated Timestamps only resolve down to milliseconds....
Joachim