Import & Timezone issue in 7.0.0.17

[tomtomer]

I'm trying to import the following two lines in an empty historical database. It is failing saying that timestamp in line 1 is smaller/equal than the timestamp of the following line.

It fails with (end of bar, bid, UTC), but when I change it to (end of bar, bid, UTC+1), it succeeds. Local timezone is UTC+1 (+2 DST) in case it matters.

20071028 005900;1.43915;1.43915;1.43915;1.43915;0
20071028 010000;1.43915;1.43915;1.43915;1.43915;0

[NinjaTrader_Jason]

Hello tomtomer,

I tested these two lines on my end, however it did not result in an error. I used the same three settings as you describe.

I tried some other settings as well, however I could not reproduce the error. Can you please tell me the name of the .txt file.

[tomtomer]

Hello tomtomer,

I tested these two lines on my end, however it did not result in an error. I used the same three settings as you describe.

I tried some other settings as well, however I could not reproduce the error. Can you please tell me the name of the .txt file.

The name is $EURUSD.txt

I thought I'd also mention that those lines errored after importing about 430k lines (and then again, naturally, after putting them in their own file and removing all historical data before retrying). I have no idea why that specific pair, or their timestamps, are troublesome with UTC and not with UTC+1 ...

[NinjaTrader_Jason]

I tested it once more using the same text file name, however I do not experience an issue on my end.

When I check the Edit-tab of the Historical Data Manager the imported data is listed (see screenshot).

Could it be the two lines have a different order in the text file - the 010000 line is listed first and the 005900 line second?

[tomtomer]

I believe I pasted the lines as they were. In any case, if it was a matter of order, choosing between data timezones (UTC+1 vs UTC) shouldn't make a difference so it should have complained in all cases and not just one. If you can, maybe you could try setting your clock to UTC+1 under DST (effective UTC+2) and check whether it works...

Otherwise I'll clear the history and re-verify it again once I post another little issue I just found and see if i can reproduce it again (which I should be able to).

[NinjaTrader_Jason]

I am able to reproduce it using the same time zone set on my PC. I will forward your findings to Development. Thank you for reporting.

[tomtomer]

Thank you. If possible I'd like to hear about the causes for this issue. I'm rather curious about it, technically speaking.

[NinjaTrader_Jason]

As soon as there is information regarding the issue, I will let you know.

[NinjaTrader_Jason]

Hello tomtomer,

You will need to select the proper time zone upon importing historical data - use the time zone that is used by the timestamps in the text file.

Timestamps are converted with the assumption the proper time zone is selected. Subsequently they will be converted to the time zone on your PC clock.

Upon importing historical data that way your PC clock is set back one hour, which causes the timestamps to become out of order. If the proper time zone is selected, data would already have timestamps built with DST ending discrepancy in place.