The microsecond and nanosecond support in Time and DateTime field currently is available only in RFA 8.x version. Once RFA 7.6.x version or older application tries to decode the field published with microsecond and nanosecond (i.e. via the DataBuffer::getTime(), DataBuffer::getAsString(), DataBuffer::isBlank()), RFA will throw an invalid usage exception.

Below is the example of exception in 7.6.2 vesion.

Exception Type: InvalidUsageException
Exception Severity: Error
Exception Classification: IncorrectAPIUsage
Exception Status Text: Data decoding failed in DataBuffer::getTime(); Reason: RSSL_RET_INCOMPLETE_DATA

RFA 7.x application needs to handle the exception and continue decoding the remaining content in the message (i.e. next field entry). This means that application will not be ableto receive any value from the file. We would recommend updating RFA version to 8.x version.

Anyway, if there is no nanosecond and microsecond precision published in the Time and Date Time field, RFA 7.x will decode TIME and DATETIME data type properly.

Hi @Rupert Schilling

My understanding is that in order to convert to string, the API still needs to decode the value before it can convert.

Therefore, from a programming perspective you will either need to upgrade to v8 API or amend your code handle the exceptions - if your code does not just decode a predetermined set of fields i.e. there is a chance it will attempt to decode one of the newer fields.

From the perspective of your Market Data team, they should be provided with some workarounds they can implement at the TREP level. e.g. having a dedicated set of ADS servers for legacy API applications - where the ADS filters out / does not send out the newer fields. They should contact their technical account manager or the TREP helpdesk for further guidance.

It is may be interesting to note that in order to preserve the compatibility of existing application, the microsecond and nanosecond precision time values have only been introduced in new fields. These fields have an acronym with a suffix of “_NS” (like “ASK_TIM_NS”). This means that applications that do not try to decode these new “_NS” fields will not experience the InvalidUsageException.

Now the question is: How does your application decode the fields it receives?

• If it iterates through the whole field list and tries to decode each field whatever its name is, then it will probably experience the InvalidUsageException. To fix this issue you will have either to change your code to handle the exception (as described above by Veerapath) or to upgrade your application to RFA 8 (recommended solution).
• If your application iterates through the field list but only decodes the fields it knows (either because it recognizes them by the acronym or by the field id), then there’s no chance your application tries to decode any of the new “_NS” fields. In that case, you don’t have to worry about the exception and you can keep your RFA version. Obviously, you will not benefit from the new microsecond and nanoseconds precision.