[This message was posted by Daniel May of SpryWare, LLC <[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/ee328436 - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
