This script draws vertical lines to mark Economic Calendar Events. Datetime of events is defined by user in Settings via a standardized line of text.
Motivation for coding this script: All traders should be aware of economic calendar events. At times, when you really need to pay attention to an upcoming major event, you might even decide to use the vertical-line drawing tool to mark it. However, this takes manual effort. This script provides a solution to performing mundane tasks such as drawing vertical lines and dragging them ever so slightly, just to have them approximately aligned with exact time.
Parameters: (1) Source data - String representation of collection of datetime referencing to Economic Calendar Events (2) Line color, & (3) Width of line - For displaying vertical lines drawn by script.
Standardized format for Source Data: Example: If 'GMT;2022,6,1,14,0,0;2022,6,2,12,15,0;' is provided to PineScript, then two vertical lines will be drawn on June 6, 2022 according to the exact time in 'YYYY,MM,DD,hh,mm,ss' format at the specified timezone (GMT in this case).
Users are advised to use their preferred methods* to format the string (for source data param.), and apply their own criteria to sort down the Events. (ie. only include Events of High Impact, etc.) * Preferred methods (as mentioned above) does not mean being limited to using the template as provided in this post.
Versionshinweise
⋅
- Code clean up - Adjusted settings UI with 'text_area'
Versionshinweise
⋅
(1) Refactored, (2) Implemented fail-safe approach to ensure most recent lines get drawn, ignoring oldest events when n > 500 (max no. of lines allowed to shown on chart by pine)
Versionshinweise
⋅
Fix: To adjust for potential timing differences. Original Unix time might cause lines to offset when chart viewed on other timeframes (ie 12hour). Thanks to @jdehorty for pointing this out and letting me use his logic for converting Unix time.
Versionshinweise
⋅
changes to docstring
Versionshinweise
⋅
New feature: Multiple categories; option to show/hide, rename, and select colors for each grouping.
Outstanding work. The preprocessing strategy you used here has great potential to be used in other areas as well. Hopefully, this EP will help raise awareness that there needs to be a better mechanism for programmatically obtaining data related to the Economic Calendar.
DojiEmoji
⋅
@jdehorty, Thank you for your kind words. I guess this method can also be applied to feeding in data for strategies that go beyond being based on price action (ie weather patterns)
PineCoders
⋅
Trendoscope
⋅
Well done. This is quite frequently asked in Pine QA forums on how to get calendar events in pine.
Guess we can't rule out the possibility that it might someday be added. In the meantime, seems fun to explore DIYs.
jdehorty
⋅
@DojiEmoji This is a great effort, well done. However, one thing to consider is that all of your dates are incorrect when rendered to the chart depending on what timeframe you view them from. You will need logic to specifically account for this depending on what timeframe the user is on; feel free to reuse the switch statement in the "getUnixTime" method in the Economic Calendar indicator I linked in my other comment (below).
DojiEmoji
⋅
@jdehorty, My dates are correct. I've chosen to use Pinescript's builtin timestamp() function which takes in timezone (string) as argument in the first parameter, this does the adjusting.
But thank you for sharing your method. There's gonna be something that I can learn from it.
jdehorty
⋅
@DojiEmoji No, this is not what I am referring to; it has nothing to do with the timezone. Consider for example the FOMC Minutes scheduled for tomorrow.
The actual date of the meeting in UTC is Wednesday, November 23, 2022, at 19:00. When viewed on the hourly or daily timeframe your indicator is correct. However, switch to the 12-hour timeframe and it shows that the event will occur on Thursday, November 24, 2022, at midnight. In reality, it would make a lot more sense for the vertical line to be the candle before on Wednesday, November 23, 2022, at noon, since this is the candle during which the event actually happens.
@DojiEmoji No worries! For what it's worth, it feels like a platform-level bug to me. @PineCoders, @HeWhoMustNotBeNamed, or anyone else who may know — what is the proper channel for reporting a bug such as this? Essentially, the issue lies in the mechanism by which TradingView rounds up the Unix time behind the scenes when the corresponding DateTime falls between candles for a given timeframe. To keep things reasonable/intuitive, it really ought to be a "floor()" mechanism that resolves the final DateTime integer rather than a "ceil()" mechanism.