Support Board
Date/Time: Sat, 23 Nov 2024 18:00:52 +0000
Post From: Python for Sierra Chart
| [2023-02-25 18:05:51] |
| sgne - Posts: 104 |
|
Okay, so Kiwi's code needs to be adjusted. I don't think the long value that's extracted from the SCID, e.g. 3879765719337000, is microseconds. I'm thinking that the number can be broken down into three numbers: 3879765719 337 000. The first number is seconds since 12-30-1899. The second number is milliseconds. The third number indicates the trade number at that millisecond (000 is the first trade, 001 the second, etc.). The way I'm dealing with this, for now, is to make the long a string, discard the last three numbers, save the milliseconds as a string (337), make 3879765719 an integer, and subtract 25569 * 86400 from it (the seconds between 1899 and 1970, which Python uses). Then I run it through a time python function to get the time values and the time zone adjustment I want, then I tack on the milliseconds. So 3879765719337 = 20221209 114159.337 (eastern time). For now, I'm using the function localtime(), and the input is, in this case, 3879765719 - 25569 * 86400. Since we're dealing with integers, there's no rounding error. For NQ, milliseconds begin on Sunday 20200823. It looks like before that, the last 6 numbers aren't part of the time. They mark the trades at that second. Date Time Of Last Edit: 2023-02-25 20:00:05
|