Imported from previous forum
Most timestamps on the standard are UTC while some are local time, but when converting legacy systems to a FIX implementation, the safest, least error-prone decision is keeping all times the same as the trading engine, which for a particular case I am analyzing is exclusively in local time.
What do you guys think are the consequences of not following the standard on that regard?
Regards
Carlos Hernandez
Carlos
I would stick to using UTC. There has been a number of threads in this section relating to non-UTC times and they generally take the form of one party complaining about another’s lack of conformity.
If both FIX engines are internal (i.e., your task is regarding internal FIX messaging), I’d still be tempted to convert to UTC at the sending end, even if I knew with certainty I’d have to convert back at the other. For very low latency DMA lines I might change my mind under duress.
Don’t forget though the FIX specification on this only pertains to the FIX line itself. In most cases FIX engines have two data streams for each connection - i.e., the FIX connection itself, and on the other side a connection to the relevant application (OMS, another FIX engine, etc) that produces and consumes data from/to the FIX line. If this connection is not FIX, and the protocol pertaining to that connection doesn’t require UTC, then you can send whatever you choose (and get the FIX engine to do the necessary conversions).
But I’d probably keep the FIX side of things to UTC.
Most timestamps on the standard are UTC while some are local time, but
when converting legacy systems to a FIX implementation, the safest,
least error-prone decision is keeping all times the same as the trading
engine, which for a particular case I am analyzing is exclusively in
local time.What do you guys think are the consequences of not following the
standard on that regard?Regards
Carlos Hernandez