[This message was posted by Hanno Klein of Deutsche Börse Systems <[EMAIL PROTECTED]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/a80aa3b3 - PLEASE DO NOT REPLY BY MAIL.]
Daniel, I do not understand the difference between relative and absolute timestamps as described by you. My understanding was that HH:MM:SS.sss and msec since X are equivalent representations of an absolute timestamp, the latter simply requiring less bytes on the wire than the former. I would hope that the representation does not imply a specific calculation algorithm. Thanks, Hanno. > The more I think about this the more I see there is a chance for > inaccuracies by using the a relative timestamp rather than an absolute > timestamp. By using a relative time stamp, such as milliseconds since an > epoch, you are leaving yourself open to time skew unless you know the > specific algorithm that the sender used to calculate the timestamp. I > think to reliably use a relative timestamp both parties need to know how > the timestamp was calculated to properly interpret it. > > This wiki explains the details of an accurately calculated Unix time > stamp, including leap seconds. http://en.wikipedia.org/wiki/Unix_time > Since some users may simply rely on the host operating system to > generate this number for them, it is important to know the details of > the implementation. > > You can find a schedule of leap seconds here > http://en.wikipedia.org/wiki/Leap_second > > In the FAST 1.2 extension proposal, we should include the option of > absolute timestamps also. The has the added benefit of support > implementations like CME FAST who already are using absolute timestamps > by simple converting HH:MM:SS.sss into a UInt32 of HHMMSSsss digits. > > /Daniel > > > > > > All, > > > > > > following up on today's confcall; > > > > > > AFAICT Dan's original proposal doesn't handle leap seconds either. > > > I need to think some more about the significance of leap seconds > > > for FAST. > > > > > > If anyone has thoughts to share please post. > > > > > > Best, Rolf > > > > Disregard my leap second concern, as it seems most modern day unix > > clock implementations do adjust for leap seconds. thanks, Brian [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
