Support processing higher resolution timestamps

mail on quickfixj-users mailing list

-------- Forwarded Message --------
Subject: [Quickfixj-users] QuickFIX/J time precisions
Date: Mon, 4 Jan 2016 09:16:55 +0000
From: Yuval Cohen <[email protected]>
Reply-To: [email protected]
To: [email protected] <[email protected]>

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

FIX Standards have recently proposed changes, that require some code change in QuickFix/J.
Specifically, FIX introduced a change to the time precision to support microseconds and higher resolution timestamp.
A gap analysis made by FIX can be found by following the links in: http://www.fixtradingcommunity.org/pg/discussions/topicpost/2893609/
Please fill free to contact me directly if you need any clarifications about the new standards.

I would appreciate if anyone who is working to make the required changes will please contact me.

Kind Regards
Yuval Cohen

Etrading Software Ltd
City Tower
40 Basinghall street
London EC2V 5DE

Tel: 020 3770 5808
Mobile: 07889 176368
SkypeMe: yuval_cohen.laptop

considerations

• Is this really required? One could argue that for normal trading applications millisecond granularity is sufficient. Probably no-one is using QFJ for high-frequency trading (which would require at least microsecond granularity).
• To accept timestamps with higher granularity the probably easiest thing to do is to alter the fields in the data dictionary from UTCTIMESTAMP to STRING. That way the messages would get accepted and users could parse the fields by themselves.
  • However, a more sophisticated solution would be preferred.
• Supporting timestamps up to nanosecond precision could be implemented with reasonable effort. However, it might be required to use JDK 8 for this since nanosecond support is better.
• Picosecond granularity is totally out of scope and is also discouraged by FPL.
• We need a configuration option to decide which precision we want to send since not all counterparties might be able to deal with it, e.g. some destinations might only be ready to receive microseconds but not nanoseconds timestamps.

Also see QFJ-921 which will merely deal with accepting messages with timestamps in microseconds or nanoseconds but not with processing them.

implementation

• added support for sending/processing UtcTimestamps with up to nanosecond precision
• added config TimeStampPrecision (used for (Orig)SendingTime)which can take a value of SECONDS, MILLIS, MICROS or NANOS.
• instead of java.util.Date we will now use java.time.LocalDate/Time classes
• extended/adapted unit tests
• extended converters
• added new fields UtcTimeField and UtcDateField