DTC Protocol Discussion Forum
- DTC Protocol Discussion Forum |
- Search Board |
- Control Panel |
- View My Posts / Threads |
- Direct Messages
Date/Time: Fri, 29 Nov 2024 10:25:30 +0000
Post From: Please update DTC protocol documentation and header files
| [2022-04-01 14:08:47] |
| User406106 - Posts: 6 |
|
Thank you for updating the header file, it is much appreciated. These will not be documented because they are Sierra Chart specific and internally used
If so, would it be possible not to send the internal-only optional fields via the DTC protocol? Our platform has a high severity alert if a DTC message contains unprocessed or wrongly parsed fields. Please omit the message parts that we must ignore anyway. This is a UNIX time value in milliseconds as an integer. Sierra Chart could be sending this though in microseconds.
But it isn't, that's what I try to highlight. I'm aware of the differences of Sierra's date-time formats, that's why I could fix the issue. The header file is incorrect (the new one, too), because this field should have t_DateTime type, not t_DateTimeWithMillisecondsInt. Interestingly enough, it is incorrect only in the header file, whereas the .cpp contains the correct type: t_DateTime s_OrderUpdate::GetOrderReceivedDateTime() Example (let's use JSON encoding for better readibility): {[...]"OrderReceivedDateTime":1648819962,"LatestTransactionDateTime":1648819964.947[...]}
If I parse 1648819962 as t_DateTimeWithMillisecondsInt I get 1970-01-20 2:00 But if I parse it as t_DateTime I get the correct 2022-04-01 13:32 As for context (see also the attached screenshot): We use the C++ sources only as reference. Our platform has a meta description for all message types we need to use so it can (de)serialize the messages using any encoding (binary/var length binary/JSON/Compact JSON/protobuf). |
 2022-04-01_160129.png / V - Attached On 2022-04-01 14:02:35 UTC - Size: 42.71 KB - 550 views |