Bug: Misalignment of GetXByTime() on chart?

[Sim22]

Hi there,

I've written some code to plot certain events such as new months, years, dividend dates etc. on daily bars.

Problem: Using GetXByBarIndex on actual bars 'generally' works, however using GetXByTime usually plots a bar behind on daily bars.

I was also attempting to plot into the future and was pleasantly surprised when NT cooperated by plotting into the future using GetXByTime(), so I didn't have to rig up some dodgy calendar iteration and approximate x location.

However, that joy was short-lived, as I move the crosshairs across the chart, the axis date time label does quite a good job of showing future dates, but for some reason my lines do not align with these labels on the chart. The dates are correct, they are just not plotting where they should be.

I 'could' fix this myself but I'd rather have NT internals fixed if that is the problem.

Please observe the 2 images uploaded as I have tried to place as much detail as possible. There are subtle differences between the two.

****(Please note to avoid confusion the line Jan 19 is actually Feb 1st, it denotes the end of Jan. Also the time axis is showing Australian date format when I have communicated to you using US date format.)

Thank you.

[NinjaTrader_Jesse]

Hello Sim22,

Thank you for the post.

Would you be able to provide an example that demonstrates the problems in a simple way so that I could supply that to development for review? I would like to see the specific syntax used to reach the result that you are now.

I look forward to being of further assistance.

[Sim22]

Thanks Jesse... here is an indicator. It has been stripped down, though effective for the debug purposes. It is thoroughly commentated.

What I also noticed was that the difference of the misalignment varied from the session template used....ie. ETH futures faired better than equities, 1 to 2 days difference. Maybe there is something there ???

These snapshots are also contained within the zip file.

Thank you.

[NinjaTrader_Jesse]

Hello Sim22,

Thank you for providing the sample, I will take a look at this and report back once I have further tested and have more details on this.

I look forward to being of further assistance.

[NinjaTrader_Jesse]

Hello Sim22,

I just wanted to reply back with my findings on this item.

I was able to see the problems you presented with the future dates. In the case of future dates, this will also rely on the availability of a bar in the specified slot along with the equidistant bar spacing algorithm. When Equidistant is set to true, you're lining the time series to the bars. If you were to draw in the future using either method time or index, there is no bar at that time, so there is no Time ahead of the last bar to return. Setting Equidistant to false, the time series is based only on time which is scalable and allows you to align objects to that time period and is not tied into a bar. In this situation what we are seeing as the difference in the future seems to be expected based on how the chart bars are being built and referenced. I don't really have a suggestion here specifically as using future dates/bars is not a standard concept in the platform which is documented.

The historical offsets you mentioned I was unable to see with the script you provided as is using GetXByBarIndex, I do see that you are subtracting a year from the result in one place which is putting the Q4 text a year off for me. I also see you had done this for the months so that was putting the months one month back as well. I tried both with the subtraction and without, the only difference was seeing the correct dates above the scale when removing the subtraction, I still did not see the offsets.

I tried using GetXByTime and do see the offsets but I believe this would be expected if you are not also calculating the bar and slot size while using this method. The important difference is noted in the help guide between these two methods:

GetXByTime
Returns the chart-canvas x-coordinate of the slot index of the primary Bars object corresponding to a specified time.

GetXByBarIndex
Returns the chart-canvas x-coordinate of the bar at a specified index of a specified ChartBars object on the chart.

These are not directly interchangeable as one uses the Slot information from the primary which is not the same as the Bar information from the specified ChartBars object being used. In a single series script, these would reference the same series but this would additionally matter in a multi-series scenario. Using GetXByBarIndex would generally be suggested if you need to draw something with the specific coordinates of the bar instead of the area the bar occupies or its Slot.



I look forward to being of further assistance.

[Sim22]

Thank you for trying this out Jesse.

I do see that you are subtracting a year from the result in one place which is putting the Q4 text a year off for me. I also see you had done this for the months so that was putting the months one month back as well

This is purely for the labels, not the date alignment. This was intentional as you will notice the text is on the left of the line signifying the end of the month/year such as appears on the ThinkOrSwim platform. Obviously the issue was the x 'alignment'.

The historical offsets you mentioned I was unable to see with the script you provided as is using GetXByBarIndex

Using GetXByBarIndex historically was not the issue. If you try GetXByTime historically instead (as has been commented out in my code) it will appear a day behind on daily bars. True, I would not use this if I can use GetXByBarIndex, but it did show the GetXByTime was out by a day. Note: I am using UTC, which in this circumstance should still not matter.

Going forward --->

1. I will only be using Equidistant daily bars with this.
2. I do not need an exact 'x' location only approximate, not several days off. Therefore I am curious as to how the bottom date time axis is aligned, since it seems to "know' the future dates (give or take a weekend or public holiday of course.)...that's why I am pushing for a solution.
3. I initially thought of looping through future holidays and weekends, subtracting them from the future date, then multiplying the bar margin right of the last two bars to thus get an approximate 'x' location for the line. However, I thought this was an unnecessary hack that I shouldn't do if I could use GetXByTime instead. Obviously the hack (as always ) prevails.......

Thank you for your time.