OPEN-SOURCE SCRIPT
Security() Correction - Realtime vs. Historical Bars

Problem
Pine's implementation of the security() function behaves differently in realtime vs. historical bars. Specifically, for historical bars, calling security() for a time frame (TF) larger/slower than the current chart's TF will return information about the last completed bar of the higher TF. However, for realtime bars (i.e. if you allow the chart to continue to plot in realtime), security() returns information about the presently in-progress bar of the higher TF. Clearly, this leads to discontinuity that is arbitrarily dependent upon when the user last loaded or refreshed the chart.
Solution
Fortunately, after understanding the problem, solving it is trivial: use security() normally for historical bars, but switch to explicitly requesting prior candle bars once the indicator is operating on realtime bars. I leave the source open here for any to use as they see fit. For testing, I include an input to allow switching back and forth between standard and corrected behavior.
Figure 1 displays the standard behavior we see in security() calls, and Figure 2 displays the behavior after my correction:

Figure 1: Typical security() behavior in Pine

Figure 2: Corrected security() behavior, forcing historical and realtime bars to refer to the same higher TF bar offset.
I publish this mostly as a reminder to myself, so I will not forget and then have to figure it out again next time it comes up in my scripting.
V21: Initial release.
Pine's implementation of the security() function behaves differently in realtime vs. historical bars. Specifically, for historical bars, calling security() for a time frame (TF) larger/slower than the current chart's TF will return information about the last completed bar of the higher TF. However, for realtime bars (i.e. if you allow the chart to continue to plot in realtime), security() returns information about the presently in-progress bar of the higher TF. Clearly, this leads to discontinuity that is arbitrarily dependent upon when the user last loaded or refreshed the chart.
Solution
Fortunately, after understanding the problem, solving it is trivial: use security() normally for historical bars, but switch to explicitly requesting prior candle bars once the indicator is operating on realtime bars. I leave the source open here for any to use as they see fit. For testing, I include an input to allow switching back and forth between standard and corrected behavior.
Figure 1 displays the standard behavior we see in security() calls, and Figure 2 displays the behavior after my correction:
Figure 1: Typical security() behavior in Pine
Figure 2: Corrected security() behavior, forcing historical and realtime bars to refer to the same higher TF bar offset.
I publish this mostly as a reminder to myself, so I will not forget and then have to figure it out again next time it comes up in my scripting.
V21: Initial release.
開源腳本
秉持TradingView一貫精神,這個腳本的創作者將其設為開源,以便交易者檢視並驗證其功能。向作者致敬!您可以免費使用此腳本,但請注意,重新發佈代碼需遵守我們的社群規範。
免責聲明
這些資訊和出版物並非旨在提供,也不構成TradingView提供或認可的任何形式的財務、投資、交易或其他類型的建議或推薦。請閱讀使用條款以了解更多資訊。
開源腳本
秉持TradingView一貫精神,這個腳本的創作者將其設為開源,以便交易者檢視並驗證其功能。向作者致敬!您可以免費使用此腳本,但請注意,重新發佈代碼需遵守我們的社群規範。
免責聲明
這些資訊和出版物並非旨在提供,也不構成TradingView提供或認可的任何形式的財務、投資、交易或其他類型的建議或推薦。請閱讀使用條款以了解更多資訊。