Wrong Pivot points on Futures NQ and DJ

Forums ProRealTime English forum ProBuilder support Wrong Pivot points on Futures NQ and DJ

Viewing 15 posts - 31 through 45 (of 53 total)
  • #227580

    Can you test this last one at same barindex as previously ?

    #227589

    Attached, thank you

    #227599

    Weird, dayofweek is supposed to change at 1 am (at the end of the bar that begin at 0h55min to be more accurate, not at 7 am…

    Is it the same for Allemagne 40 (DAX) ?

    #227600

    Yes it is a known problem on PRT with  futures. That s why in one of the first post i have included a code correcting this.

    #227603

    Yes it is a known problem on PRT with futures. That s why in one of the first post i have included a code correcting this.

    Is your Nasdaq future is differnt from US Tech 100 CFD (from IG) ? If it is, tell me how you do to put the Nasdaq future on PRT so i will be able to solve your problem… The code i posted works for CFD index that have Dayofweek change at 1 am. Mayb i need an other broker ?

    If i want to do the same for future i have to do sevral tests while coding it…

    1 user thanked author for this post.
    #227604

    To access the futures you would need to use the “other” PRT (with broker IB) a demo account is enough. Probuilder code is the same.

     

    Then instead of searching for us tech 100… you search for NQXXXX

    Then you have the futures nasdaq in front of the eyes ! 🙂 thank you a lot

    #227606
    #227625

    Now it works.

    The problem was the use of Close[1] instead of DClose(1) which corresponds is the Settlement Price (Prix de Règlement) and can be different from Close[1].

    Here the code which works and which “correct” also the PRT bug about the fact that the dayofWeek changes only at 7:00 on some futures.

    Thank you a lot LucasBest for your valuable support. If you see any improvements to be brought to this code, it is very welcome, I saw you publish a lot of good things here on the forum…

     

     

    1 user thanked author for this post.
    #227626

    Remain still the problem of managing the hours changes… summer/winter : sometimes the day does not change at 7:00 but at 6:00

    #227628

    For 2023 I have just brought weeksofShift and TimeOfDayChange pfor managing the week difference between Paris and US…

    weeksOfShift = (myMonth=3 and (myDay>=12 and myDay<=26)) or ((myMonth=10 and myDay>=29) or (myMonth=11 and myDay<=5))
    if weeksOfShift then
    TimeofDayChange=055959
    else
    TimeofDayChange=065959
    endif

    Now I am looking for a code which defines the date (day and month) of the last sunday of March and the last sunday of October  automatically (for a given year)

    #227633

    Jerome, that will not help you, as it is not only about our Daylight Saving but also about the US. In the past years I experienced a difference that lasted 1 week, 2 weeks and even 3 weeks.
    The rule in the US I don’t know. Ours is what you suggested (end of March etc.).

    Peter

    1 user thanked author for this post.
    #227634

    Thank you Peter, I think you are right, a manual entry for each year is better

    #227635

    The problem was the use of Close[1] instead of DClose(1) which corresponds is the Settlement Price (Prix de Règlement) and can be different from Close[1].

    Wow, I did not know this existed. But exactly as what was asked here : and with this response from Nicolas :

    Dclose returns the official daily close of the instrument.

    which to me in the context of the “constant” is the same as No answer … would it be true indeed that for the DAX this would return 17:30 ? Please remember, the DAX closes at 22:00.
    It would mean 22:00 for ES and NQ (etc.) which close at 23:00.

    Of course I like to believe you. Did you test this ? (which I could do myself – haha).
    The manual (“Programming Guide” – ProBacktest and ProOrder) does not tell much about it. And if anything it is what Nicolas literally said (quote above). The manual speaks in the context of “and it does not depend on your TimeZone settings”. Not that I can warp my head around that. 🙂

    Curious …

    #227636

    Thank you Peter, I think you are right, a manual entry for each year is better

    I am quite sure you don’t need this. So just in case :

     

    1 user thanked author for this post.
    #227637

    … If DClose really would do what you describe, it would even solve the problem of White Thursday, Good Friday and other crazy stuff like following Easter on Monday which does not exist in the US, but where they these days make up various other holidays on such days (as Easter Monday). N.b.: I think in this thread you talked about this too ?
    Anyway, we could make an indicator for that, so we can just see it coming, instead of trying to look it up for the xth time, knowing that IBKR is sparse with such data (IG is OK).

    PS: The crazy stuff is about not being able to judge your daily gain properly because it depends on the Settlement dates/times (DAX is a daily pain if you’re not used to it).

     

    1 user thanked author for this post.
Viewing 15 posts - 31 through 45 (of 53 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login