Imported from previous forum
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.
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.
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
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.
We should always separate the semantic of the field from its encoding. Obviously, we all think of ASCII tag=value when talking about FIX but there are already two more, i.e. FIXML and FAST that leads to a different wire representation. FIX 5 also allows to use a different transport which is typically equal to having neither ASCII tag=value nor FAST nor FIXML. Latency sensitive applications will rather look at FAST where timestamps can be efficiently encoded since FAST 1.2 (http://fixprotocol.org/documents/4322/FAST%201%202%20Extension%20Proposal%20v10.doc).
There is also a document on FIX over FAST which addresses encoding guidelines in more detail (http://fixprotocol.org/documents/4652/FIX%20Messaging%20Over%20FAST%20V1.01.pdf).
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.