FAST and UTCTimestamp and UTCTimeOnly Fields

, ,
1

Imported from previous forum

2

[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi David

Do we have a compact way of representing UTCTimestamp and UTCTimeOnly fields in FAST? If represented as strings these would occupy bulk of the message size.

Regards
Darshan

3

Hi David

Do we have a compact way of representing UTCTimestamp and UTCTimeOnly
fields in FAST? If represented as strings these would occupy bulk of the
message size.

Regards Darshan

Hi Darshan,

we have seen that using delta strings yields a high level of compaction.

It would be nice if the FIX mapping layer would define that use of int64 for a time or date field in a template should be interpreted as the number of milliseconds (or microseconds) since epoch (e.g 1970-01-01).
The combination of int64 and delta would compress very well, while making encoding and decoding of dates and times faster processing wise.

Kind Regards,
Anders

4

In our implementation, and the FPL POC, we used milliseconds since Midnight for time, and YYYYMMDD for date, encoding as UInt32 values. This works well with Increment encoding for the time and Copy encoding for the date. I do not think UTCTimeOnly in the FIX world supports microseconds, so the suggestion by Anders of using milliseconds since the epoch would work nice, and fit into a UInt32.

/Daniel

Hi David

Do we have a compact way of representing UTCTimestamp and UTCTimeOnly
fields in FAST? If represented as strings these would occupy bulk of the
message size.

Regards Darshan