Jerome888 wrote:

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].

Jerome, if you don’t mind me interfering …

So you are using DClose explicitly to solve your problem ? (I hope I followed sufficiently). Well, personally me does not see any relationship with a Settlement time *if* that is related anyway (I still like to believe you, but for other reasons, as I described). Thus :

There is no way in my mind that I would consider the Settlement of e.g. the DAX (and much more European stuff) to be leading to the closing of the last day. Thus, to me this is BS, never mind that e.g. Bloomberg et all officially use the profit (or loss) of such a Future – gained past 17:30 – in the next day’s “So how does Europe do today”. It just makes no sense. 22:00 does (to me).

This could be slightly different for NQ and such, because of Q figures reported after 22:00 – and before real closing (23:00). The working is the same as with DAX (the profit/loss after 22:00 counts for the next day) because because Q figures are a kind of “unreal” for the last trading day, I myself tend to deem that surrogate and I will look at what happens the next day (e.g. what Tesla loses at 12% in the period between 22:00 and 02:00 (but which contributes to Futures from 22:00 and from 00:00 to 02:00 and eventually from 10:00 to 15:30 as well) … may end up as -7% at 15:30.
If you can’t follow my reasoning – fine, because it is personal (trading “vision”). Put I think the point remains : Settlement time (and day) can hardly be related for real to Pivot Points in the sense of your thread.

That DClose may return 22:00 instead of 23:00 is something else.
And that DClose may return 17:30 instead of 22:00 (which I actually don’t believe”) makes it plain wrong to work with. But please remember, this is my personal vision.

Lastly, in any event it may change your mind on what’s right and what’s wrong to the sense of Close vs DClose, and it may make you think that the problem is not solved at all. By coincidence it could work out for the better. Last week. But not next week.

Btw, what about Expiration ? The price would change drastically. That too is surrogate, but in the mean time it technically happens (weighing in of future Interest for the coming 3 months).

image_2024-02-08_092316704.png

LucasBest wrote:

Can you try this code and tell m if it works well for daily pivots? Can you do a screen shot at same bar as previously and add daily embeded PRT pivots to see when it change the day compares to that code ? (indicator blow price please)

Hi Lucas,

The embedded PRT Pivot Indicator won’t show in the pane below (or I don’t know how to do that today). But anyway, for yesterday it is exactly the same as yours. 17782,42.

The TF I used here is 1 minute.

image_2024-02-08_095613391.png

Hi Peter,

i was talking about my indicator in the table below and PRC embeded pivots on price, to be able to check when exactly the day change for PRX pivots and for my indicator…

Let’s try if now my indicator have the good monthly Pivot ?

ONCE DayH = high
ONCE DayL = low
ONCE DayC = close
ONCE FullDay = 0
ONCE FullWeek = 0
ONCE FullMonth = 0

IF (DAYOFWEEK=DAYOFWEEK[1] and DAYOFWEEK<>DAYOFWEEK[2] and dayofweek>1) or (dayofweek<DAYOFWEEK[1]) then

drawvline(barindex)

if dayofweek <> 1 or (dayofweek<DAYOFWEEK[1]) THEN
PivotDuJour  = (DHigh(1) + DLow(1) + DClose(1)) / 3
elsif dayofweek = 1 then
PivotDuJour  = (DHigh(2) + DLow(2) + DClose(2)) / 3
endif

MonthH = max(MonthH,DayH)
MonthL = min(MonthL,DayL)
MonthC = DayC
WeekH = max(WeekH,DayH)
WeekL = min(WeekL,DayL)
WeekC = DayC


pDayofWeekI = DayofWeekI
pDayI = DayI
pDayH = DayH
pDayL = DayL
pDayC = DayC
DayofWeekI = DayofWeek
DayI = Day
DayH = High
DayL = Low
DayC = Close

If FullDay then
DayPivot = (pDayH + pDayL + pDayC)/3
Else
DayPivot = undefined
FullDay = 1
Endif

If DayofWeekI < pDayofWeekI then
pWeekH = WeekH
pWeekL = WeekL
pWeekC = WeekC
WeekH = High
WeekL = Low
WeekC = Close

If FullWeek then
WeekPivot = (pWeekH + pWeekL + pWeekC)/3
Else
WeekPivot = undefined
FullWeek = 1
Endif
//drawvline(barindex)
Endif

If DayI < pDayI then
pMonthH = MonthH
pMonthL = MonthL
pMonthC = MonthC
MonthH = High
MonthL = Low
MonthC = Close

If FullMonth then
MonthPivot = (pMonthH + pMonthL + pMonthC)/3
Else
MonthPivot = undefined
FullMonth = 1
Endif
//drawvline(barindex)
Endif

ENDIF

DayH = max(DayH,high)
DayL = min(DayL,low)
DayC = close

Return MonthPivot

BtW it’s LucasBest (other computer/other account)

I can’t get this right; regarding the month, there’s too much vagueness involved.** I suppose PRT is doing it right, but I did not even check that. It should be based on how DClose works, but a CloseMonth does not exist. Btw, an OpenMonth does exist, but the issues could be the same as already pointed out (gap). Otoh, you could attest that on a month’s period this is not so important ?
Which brings me to …

Why would someone use a Pivot point per calendar month ? I understand … if we use a TF of 1 month we would technically need that. But (again) IMO that is useless because markets don’t work like that. Per Day yes. Per Week yes, but per Month ? not that I can see. Maybe per Year or from Christmas to Christmas, Black Friday to Black Friday.

**): Also again think about the Settling time. Thus, if DClose has proven to work well and uses Settling time (and Lucas can mimic that), then at Dec. 29 possibly similar was happening (I think I recall that US Futures closed at 19:15). This invalidates all testing because settling has been on Jan 2 – or maybe not even that. And if it was for the DAX then maybe for the NQ it was not so (it could have been a day off in the US) and Settlement was postponed to Wednesday Jan. 3 22:00.