Hi, I have following issues related to the time and date fields.
Can there be scenarios where time or date related field will have different types like date, time or times stamp.
Also what is the time zone which used in the Reuters to published the time and date related fields.
Format of the time can this be changed in different messages.
Can there be any scenario where time related values have any invalid values, for example hours have value like 50
"Can there be scenarios where time or date related field will have different types like date, time or times stamp."
Not sure I understand the question. A given field is always one of DATE, TIME or DATETIME. In real-life only DATE and TIME are used on the Thomson Reuters consolidated feed but other feeds may use DATETIME. So your application should be prepared to meet DATETIME too.
"Also what is the time zone which used in the Reuters to published the time and date related fields."
Always UTC.
"Format of the time can this be changed in different messages."
No, there's no format. When the values travel the wire they do so as ints.
"Can there be any scenario where time related values have any invalid values, for example hours have value like 50"
Theoretically the API used to produce the message should make this impossible. However, I do not doubt that it is still possible. TR had a bug (now corrected) whereby invalid month values were produced inside the ADH when it tried to convert from the legacy Marketfeed format into OMM/RWF format. But that is all history. I guess it depends a little bit on the API being used on the consumer side. Some APIs will most likely throw an exception if there's an attempt to populate a TIME, DATE or TIMESTAMP value with invalid values. I know this is the case for RFA Java.
Thanks
About the first question.
What I want to know is whether the data type of date or time field can change dynamically
for example if we consider "Trade Date" field with field id 16, can this field's type be date on one instance and datetime in other. maybe depending on the source.
No, field type won't change like that. Otherwise the consumer won't be able to decode the field if it keep changing type.
