[This message was posted by Mikael Brannstrom of Nordic Growth Market <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/0215bf97 - PLEASE DO NOT REPLY BY MAIL.]
When using FAST it seem to be common to use milliseconds since epoch (January 1, 1970 UTC) as an uInt64 even though the field is a string in FIX. The delta operator will keep this value small. Thus, it is already a bilateral agreement what the granularity is (i.e. milliseconds or seconds). Changing this to microseconds or nanoseconds since epoch would be a minor change. It must also be stated if leap seconds are added or not. Regarding the length of the field in FIX tag=value syntax, is it really a concern? If bandwidth is an issue, why don't use FAST? /Mikael > The ability to have timestamps with microsecond or nanosecond precision would > certainly be useful. > > However, the length of such timestamps may be a concern. We are already at 21 > characters with milliseconds. Implementations that require microsecond or > nanosecond precision in timestamps may also be those that are concerned about > message size. However, the use of FAST (and the Tail operator) may mitigate > the impact of longer timestamps on market data feeds. > > Should alternate methodologies for timestamps be considered (e.g. nanoseconds > since midnight, nanoseconds since 1-Jan-1970, etc.)? > > > > > > > We had the issue raised in the GExMC call today where a market place wants > > to assign an additional identifier to circumvent the issue of FIX > > UTCTimestamp field only having millisecond resolution. > > > > It appears to me that the ISO 8601 standard(2004) and the W3C proposal that > > was submitted to ISO 8601 in 1997 – specifies that the second field is > > defined as ss.s (where .s is a fraction of a second). > > > > We codified into FIX the use of three decimal places to represent > > millisecond: ss.mmm > > > > But, my reading of the W3C and the ISO 8601:2004 standard does not specify > > the resolution of the decimal fraction. > > > > “the number of seconds elapsed after the last full minute, with decimal > > parts of a second if necessary.” (Section 3.2.3, p. 10, ISO 8601:2004 > > standard). > > > > From my reading it seems like we could extend by counterparty agreement the > > resolution of the UTCTimestamp to include additional resolution is > > permissible. For instance we could extend the format by counterparty > > agreement to: SS.mmmuuunnn (where m is milliseconds, u is microseconds, > > n-nanoseconds). > > > > Would like to get others thoughts and opinions on this. [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.
