Support Board
Date/Time: Wed, 16 Sep 2026 17:42:51 +0000
ZNU12-CBOT historical SCID timestamps reverse after a fresh SC Data download
View Count: 18
| [2026-09-16 15:06:41] |
| Thiag094 - Posts: 1 |
|
Please investigate an out-of-order timestamp in the historical intraday data for the individual contract ZNU12-CBOT. Environment: Sierra Chart 2933, service SC Data, Intraday Data Storage Time Unit = 1 Minute, maximum historical non-tick days = 730. On September 16, 2026, with Sierra disconnected and this chart closed, I preserved the existing SCID under another filename. I then opened ZNU12-CBOT and connected to download a new file. The original active file was absent before this request. No continuous-contract adjustment, import, sorting or editing was applied. The Message Log identified request 71, server ds28.sierracharts.com, a 60-second interval, and 90,654 records received and written. Completion was at 12:22:08 UTC. The resulting file has 3,626,216 bytes and is byte-for-byte identical to the preserved original. Reading the raw SCID records in file order gives this adjacent pair (zero-based record indices, decoded timestamps in UTC): 39448: 2012-07-08 19:02:00; O/H/L/C 134.296875; NumTrades 1; TotalVolume 9; BidVolume 0; AskVolume 9 39449: 2012-07-08 19:01:56; O/H/L/C 134.296875; NumTrades 1; TotalVolume 9; BidVolume 0; AskVolume 9 The timestamp goes backwards four seconds, across a minute boundary. The other 32 bytes of these two records match. The full file SHA-256 is A4486F49249A38FAC790BBBF8B2C1F99D504BA0B2ACC25151D8BFD715D11419D. Is this an error in the historical data, or expected behavior of this older data format/storage process? If it is an error, could you correct the source or provide the supported correction procedure? We have preserved both copies unchanged. The same file-order check also flags ZNM11-CBOT, ZNU11-CBOT, ZNZ11-CBOT, ZNH12-CBOT and ZNM12-CBOT, but only ZNU12-CBOT has undergone this controlled fresh-download comparison. I understand from the Intraday Data File Format documentation that timestamps are UTC and a one-minute record can start at its first trade, rather than at second zero. The reported issue is the reversal across a minute boundary, not the presence of nonzero seconds. Thank you. |
To post a message in this thread, you need to log in with your Sierra Chart account: