Enhanced Gann Time-Price SquaresEnhanced Gann Time-Price Squares Indicator
A comprehensive Pine Script indicator that identifies and visualizes W.D. Gann's time-price square formations on your charts. This tool helps traders spot potential market turning points where time and price movements align according to Gann's legendary market theories.
Key Features:
Automatic Square Detection - Identifies completed squares where price movement equals time movement
Future Projections - Shows forming squares with projected completion points
Pivot Integration - Automatically detects pivot highs/lows as square starting points
Visual Clarity - Clean box outlines with customizable colors and styles
Smart Filtering - Prevents overlapping squares and includes minimum move thresholds
Real-time Status - Information table showing current square formations
How to Use:
The indicator draws boxes when price moves from pivot points equal the time elapsed (number of bars). Green squares indicate upward movements, red squares show downward movements. Dashed lines show forming squares, while dotted lines project where they might complete.
Settings:
Adjust pivot sensitivity and minimum price moves
Customize tolerance for time-price matching
Toggle projections, labels, and visual elements
Fine-tune colors and line styles
Perfect for Gann theory practitioners and traders looking for time-based market analysis. The squares often coincide with significant support/resistance levels and potential reversal points.
Compatible with all timeframes and instruments.
More updates to follow
ZAMAN
Your trading time period background fillThis script allows you to add background highlights to charts during any regional trading session, customize your own trading time, and is precise and customizable yet simple and easy to use, making it more convenient to review transactions.
Support global mainstream time zones: The drop-down list includes 30 commonly used IANA time zones (default is Asia/Shanghai) (such as Asia/Shanghai, America/New_York, Europe/London, etc.), one-click switching, no need to manually calculate the time difference.
Fully localized time input: "Start hour/minute" and "End hour/minute" are filled in with the local time of the selected time zone. The end hour defaults to 23:00 and can be adjusted to 0-23 at will.
Accurate time difference splitting: The script internally splits the time zone offset into whole hours and remainder minutes (supports half-hour zones, such as UTC+5:30), and ensures that all parameters are integers when calling timestamp to avoid errors.
Dynamic background rendering: Each K-line is judged according to the UTC timestamp whether it falls within the set range. If it meets the time period, it will be marked with a semi-transparent green background, and it will return to its original state after crossing the time period, helping you to identify the opening, closing or active period of any market at a glance.
Wide range of scenarios: It can be used for time-sharing highlighting of all-weather varieties of foreign exchange and cryptocurrency, and can also be used in conjunction with backtesting and timing strategies to only send signals during the active period of the target market, greatly improving trading efficiency and strategy accuracy.
Just select the region and set the time, and the script will automatically complete all complex time zone conversions and drawing, allowing you to focus on the transaction itself.
👽 TIME PERIODS👽 TIME PERIODS v1.15
Visualize key time divisions and session levels on any chart:
• Timezone‐aware session shading
– Highlight active NY session (configurable HHMM–HHMM and days)
– Adjustable background opacity
• Weekly & Monthly Separators
– Toggle on/off
– Custom color, style (solid/dashed/dotted) & width
• Day-of-Week Labels
– Diamonds at session start for M–S
– Toggle on/off
• Session Open Line
– Horizontal line at each session’s open
– Configurable color, width & “distanceRight” in bars
– Always shows current session
• Midpoint Vertical Line
– Plots halfway between session open & close
– Custom color, style & width
– Toggle on/off
▶ All elements grouped for easy parameter tweaking
▶ Fully timezone-configurable (default America/New_York)
▶ Version 1.15 — added distanceRight feature & current session support
Use this to see exactly where your chosen session, weekly/monthly boundaries, and intraday pivot points fall—across any timeframe.
Simple Candle Countdown TimerDescription:
This lightweight and customizable TradingView indicator displays a real-time countdown timer for the current candle directly on your chart. The timer updates every second and shows the time remaining until the current candle closes, in the format MM:SS.
🔧 Features:
Adjustable X/Y offset to position the timer anywhere on the chart
Customizable text color, background color, and text size
Clear and minimal design for easy visibility
Ideal for scalpers, intraday traders, or anyone who wants precise awareness of candle close timing.
Time LevelsTime Levels is a customizable TradingView indicator designed to mark critical intraday price levels based on specific time inputs. This tool helps traders identify significant Open/High/Low/Close (OHLC) levels, support & resistance (S&R) zones, and potential Judas Swing manipulation points—aligned with selected timeframes and adjusted to any time zone via UTC offset.
🔧 Key Features:
OHLC/OLHC Levels: Automatically draws horizontal lines at the candle’s open price for up to four specified time points. Ideal for marking session opens, closes, or key intraday levels.
Support & Resistance Zones: Highlights two time-based S&R levels that can help identify discount and premium pricing zones.
Judas Swing Detection: Marks potential liquidity grab zones (Judas Swings) at three user-defined times, assisting in identifying manipulation and smart money entry points.
Global Timezone Support: Includes a UTC offset input to align levels accurately with your trading session, regardless of your location.
Full Customization: Personalize the color, style (solid, dashed, dotted), and thickness of each line independently for OHLC, S&R, and Judas levels.
🛠️ Use Cases:
New York / London open price tracking
ICT-based SMC level marking
Predefined time-based liquidity level visualizations
Institutional-level price reactions (e.g., during specific market opens)
This indicator is best suited for intraday and short-term (especially ICT) traders looking to bring precision and consistency into their technical analysis framework.
Velez Price Action Signals (with 20 & 200 SMA)Velez Price Action Signals – With 20 & 200 SMA Overlay
This TradingView Pine Script is a clean and powerful reversal signal tool inspired by Oliver Velez’s price action philosophy, enhanced with trend context via two Simple Moving Averages.
🔍 Signal Logic
Buy Signal:
Current candle sweeps below the previous 5-bar low (liquidity grab).
Candle is bullish (close > open).
The lower wick is significantly larger than the body (e.g. ratio > 1.5).
Sell Signal:
Current candle sweeps above the previous 5-bar high.
Candle is bearish (close < open).
The upper wick is significantly larger than the body.
Signals appear as BUY/SELL labels on the chart (non-repainting).
Yearly History Calendar-Aligned Price up to 10 Years)Overview
This indicator helps traders compare historical price patterns from the past 10 calendar years with the current price action. It overlays translucent lines (polylines) for each year’s price data on the same calendar dates, providing a visual reference for recurring trends. A dynamic table at the top of the chart summarizes the active years, their price sources, and history retention settings.
Key Features
Historical Projections
Displays price data from the last 10 years (e.g., January 5, 2023 vs. January 5, 2024).
Price Source Selection
Choose from Open, Low, High, Close, or HL2 ((High + Low)/2) for historical alignment.
The selected source is shown in the legend table.
Bulk Control Toggles
Show All Years : Display all 10 years simultaneously.
Keep History for All : Preserve historical lines on year transitions.
Hide History for All : Automatically delete old lines to update with current data.
Individual Year Settings
Toggle visibility for each year (-1 to -10) independently.
Customize color and line width for each year.
Control whether to keep or delete historical lines for specific years.
Visual Alignment Aids
Vertical lines mark yearly transitions for reference.
Polylines are semi-transparent for clarity.
Dynamic Legend Table
Shows active years, their price sources, and history status (On/Off).
Updates automatically when settings change.
How to Use
Configure Settings
Projection Years : Select how many years to display (1–10).
Price Source : Choose Open, Low, High, Close, or HL2 for historical alignment.
History Precision : Set granularity (Daily, 60m, or 15m).
Daily (D) is recommended for long-term analysis (covers 10 years).
60m/15m provides finer precision but may only cover 1–3 years due to data limits.
Adjust Visibility & History
Show Year -X : Enable/disable specific years for comparison.
Keep History for Year -X : Choose whether to retain historical lines or delete them on new year transitions.
Bulk Controls
Show All Years : Display all 10 years at once (overrides individual toggles).
Keep History for All / Hide History for All : Globally enable/disable history retention for all years.
Customize Appearance
Line Width : Adjust polyline thickness for better visibility.
Colors : Assign unique colors to each year for easy identification.
Interpret the Legend Table
The table shows:
Year : Label (e.g., "Year -1").
Source : The selected price type (e.g., "Close", "HL2").
Keep History : Indicates whether lines are preserved (On) or deleted (Off).
Tips for Optimal Use
Use Daily Timeframes for Long-Term Analysis :
Daily (1D) allows 10+ years of data. Smaller timeframes (60m/15m) may have limited historical coverage.
Compare Recurring Patterns :
Look for overlaps between historical polylines and current price to identify potential support/resistance levels.
Customize Colors & Widths :
Use contrasting colors for years you want to highlight. Adjust line widths to avoid clutter.
Leverage Global Toggles :
Enable Show All Years for a quick overview. Use Keep History for All to maintain continuity across transitions.
Example Workflow
Set Up :
Select Projection Years = 5.
Choose Price Source = Close.
Set History Precision = 1D for long-term data.
Customize :
Enable Show Year -1 to Show Year -5.
Assign distinct colors to each year.
Disable Keep History for All to ensure lines update on year transitions.
Analyze :
Observe how the 2023 close prices align with 2024’s price action.
Use vertical lines to identify yearly boundaries.
Common Questions
Why are some years missing?
Ensure the chart has sufficient historical data (e.g., daily charts cover 10 years, 60m/15m may only cover 1–3 years).
How do I update the data?
Adjust the Price Source or toggle years/history settings. The legend table updates automatically.
Time-based LiquidityThis indicator automatically marks important time-based liquidity levels on your chart, helping you stay aware of where major price reactions may occur and the market is forced to show its hand.
Key Features:
Previous Month’s, Week’s, and Day’s Highs and Lows: Displays PMH/PML, PWH/PWL, and PDH/PDL — key reference points where liquidity often accumulates.
Intraday Session Highs and Lows: Divides the trading day into quarters (00:00–06:00, 06:00–12:00, etc. following Day’s Quarterly Theory) and tracks session highs and lows dynamically across these periods.
Current Session 90-Minute Quarters: Splits the active session into 90-minute intervals to highlight short-term liquidity structures and potential reaction zones.
Level Alerts: Tracks when each liquidity level is reached and enables customizable alerts so you don’t miss important price movements.
Use Case:
This tool provides an organized, time-based framework for identifying where liquidity is likely to concentrate across different timeframes and intraday cycles. Use these levels for forming bias, planning entries, exits, or anticipating price reactions at key points in the market structure.
Customization Options:
Enable/disable liquidity levels to display (Daily, Weekly, Monthly, Sessions, Session Quarters)
Customize the appearance of each level (color, style, line width)
Enable or disable tracking and alerts for level interactions
Zig Zag Trend Metrics“ Zig Zag Trend Metrics ” is a highly versatile indicator, built on the classic Zig Zag concept and thoughtfully designed for technical traders seeking a deeper, more structured view of market dynamics. This tool identifies significant swing highs and lows, classifies them, and annotates each with key metrics, offering a precise snapshot of each movement. It enhances visual analysis by drawing connecting lines that outline the flow of market structure, making trend progression and reversals instantly recognizable. Beyond visual mapping, it features a compact, real-time statistics table that calculates the average price and time deltas for both bullish and bearish swings, giving traders deep insights into trend momentum and rhythm. With extensive customization options, this indicator adapts seamlessly to vast trading styles or chart setups, empowering traders to spot patterns, evaluate trend strength, and make more confident, data-backed decisions.
❖ FEATURES
✦ Automatic Swing Detection
At its core, this indicator automatically identifies swing highs and lows based on a customizable lookback period (default: 10 bars).
✦ Labeling Swing Points
Each swing is visualized with a label that includes:
Swing Classification : “HH” (Higher High), “LH” (Lower High), “LL” (Lower Low), or “HL” (Higher Low).
Price Difference : Displayed in percentage or absolute value from the previous opposite swing.
Time Difference : The number of bars since the previous swing of the opposite type.
These labels offer traders clear, immediate insight into price movements and structural changes.
✦ Visual Lines
The indicator draws three types of lines:
Bullish Lines: Connect recent swing lows to new swing highs, indicating uptrends.
Bearish Lines: Connect recent swing highs to new swing lows, indicating downtrends.
Range Lines: Connect consecutive highs or lows to outline price channels.
Each line type can be color-coded and customized for visibility.
✦ Statistics Table
An on-screen metrics table provides a live summary of trends. Script uses Relative Averaging to smooth price and time changes. This prevents outliers from distorting the data and provides a more reliable sense of typical swing behavior.
Uptrend Metrics: Shows average price and time differences from recent bullish swings.
Downtrend Metrics: Shows the same for bearish swings.
🛠️ Customization Options
Ability to tailor the indicator to suit their strategy and aesthetic preferences:
Swing Period: Adjust sensitivity to short- or long-term swings.
Color Settings: Customize line and label colors.
Label Display: Choose between absolute or percentage price differences.
Table Settings: Modify size, location, or visibility.
This makes the indicator highly flexible and useful across various timeframes and assets.
Personal Time Zone: Days of WeekThis is probably the simplest indicator I have ever made.
It just gives you a the days of weeks in your specified time zone and puts the day on the first bar in your time zone.
You can use UTC time format or named time zones like the default.
Just for fun I tried to give it symbols that sort of relate the old gods that the days of week were named after and even colors that one could argue match, but it was all in fun because it was so simple I felt I had to add something.
Enjoy.
Daily Time MarkerThis TradingView indicator draws thin, white, dashed vertical lines on the chart at a user-defined time each day. The indicator takes into account Daylight Saving Time (DST) adjustments, ensuring the correct time is displayed throughout the year.
Key Features:
✅ Daily Vertical Markers:
Displays vertical dashed lines from Monday to Friday at the selected time.
The lines extend infinitely in both directions.
✅ Historical & Future Projection:
Shows lines 15 days into the past and 5 days into the future for better visualization of key time levels.
✅ DST Adjustment:
Automatically adjusts between summer and winter time , ensuring the correct hour is displayed.
This indicator is useful for traders who rely on specific time-based events, such as market opens or key trading sessions.
Quarterly Theory ICT 02 [TradingFinder] True Open Session 90 Min🔵 Introduction
The Quarterly Theory ICT indicator is an advanced analytical system built on ICT (Inner Circle Trader) concepts and fractal time. It divides time into four quarters (Q1, Q2, Q3, Q4), and is designed based on the consistent repetition of these phases across all trading timeframes (annual, monthly, weekly, daily, and even shorter trading sessions).
Each cycle consists of four distinct phases: the first phase (Q1) is the Accumulation phase, characterized by price consolidation; the second phase (Q2), known as Manipulation or Judas Swing, is marked by initial false movements indicating a potential shift; the third phase (Q3) is Distribution, where price volatility peaks; and the fourth phase (Q4) is Continuation/Reversal, determining whether the previous trend continues or reverses.
🔵 How to Use
The central concept of this strategy is the "True Open," which refers to the actual starting point of each time cycle. The True Open is typically defined at the beginning of the second phase (Q2) of each cycle. Prices trading above or below the True Open serve as a benchmark for predicting the market's potential direction and guiding trading decisions.
The practical application of the Quarterly Theory strategy relies on accurately identifying True Open points across various timeframes.
True Open points are defined as follows :
Yearly Cycle :
Q1: January, February, March
Q2: April, May, June (True Open: April Monthly Open)
Q3: July, August, September
Q4: October, November, December
Monthly Cycle :
Q1: First Monday of the month
Q2: Second Monday of the month (True Open: Daily Candle Open price on the second Monday)
Q3: Third Monday of the month
Q4: Fourth Monday of the month
Weekly Cycle :
Q1: Monday
Q2: Tuesday (True Open: Daily Candle Open Price on Tuesday)
Q3: Wednesday
Q4: Thursday
Daily Cycle :
Q1: 18:00 - 00:00 (Asian session)
Q2: 00:00 - 06:00 (True Open: Start of London Session)
Q3: 06:00 - 12:00 (NY AM)
Q4: 12:00 - 18:00 (NY PM)
90 Min Asian Session :
Q1: 18:00 - 19:30
Q2: 19:30 - 21:00 (True Open at 19:30)
Q3: 21:00 - 22:30
Q4: 22:30 - 00:00
90 Min London Session :
Q1: 00:00 - 01:30
Q2: 01:30 - 03:00 (True Open at 01:30)
Q3: 03:00 - 04:30
Q4: 04:30 - 06:00
90 Min New York AM Session :
Q1: 06:00 - 07:30
Q2: 07:30 - 09:00 (True Open at 07:30)
Q3: 09:00 - 10:30
Q4: 10:30 - 12:00
90 Min New York PM Session :
Q1: 12:00 - 13:30
Q2: 13:30 - 15:00 (True Open at 13:30)
Q3: 15:00 - 16:30
Q4: 16:30 - 18:00
Micro Cycle (22.5-Minute Quarters) : Each 90-minute quarter is further divided into four 22.5-minute sub-segments (Micro Sessions).
True Opens in these sessions are defined as follows :
Asian Micro Session :
True Session Open : 19:30 - 19:52:30
London Micro Session :
T rue Session Open : 01:30 - 01:52:30
New York AM Micro Session :
True Session Open : 07:30 - 07:52:30
New York PM Micro Session :
True Session Open : 13:30 - 13:52:30
By accurately identifying these True Open points across various timeframes, traders can effectively forecast the market direction, analyze price movements in detail, and optimize their trading positions. Prices trading above or below these key levels serve as critical benchmarks for determining market direction and making informed trading decisions.
🔵 Setting
Show True Range : Enable or disable the display of the True Range on the chart, including the option to customize the color.
Extend True Range Line : Choose how to extend the True Range line on the chart, with the following options:
None: No line extension
Right: Extend the line to the right
Left: Extend the line to the left
Both: Extend the line in both directions (left and right)
Show Table : Determines whether the table—which summarizes the phases (Q1 to Q4)—is displayed.
Show More Info : Adds additional details to the table, such as the name of the phase (Accumulation, Manipulation, Distribution, or Continuation/Reversal) or further specifics about each cycle.
🔵 Conclusion
The Quarterly Theory ICT, by dividing time into four distinct quarters (Q1, Q2, Q3, and Q4) and emphasizing the concept of the True Open, provides a structured and repeatable framework for analyzing price action across multiple time frames.
The consistent repetition of phases—Accumulation, Manipulation (Judas Swing), Distribution, and Continuation/Reversal—allows traders to effectively identify recurring price patterns and critical market turning points. Utilizing the True Open as a benchmark, traders can more accurately determine potential directional bias, optimize trade entries and exits, and manage risk effectively.
By incorporating principles of ICT (Inner Circle Trader) and fractal time, this strategy enhances market forecasting accuracy across annual, monthly, weekly, daily, and shorter trading sessions. This systematic approach helps traders gain deeper insight into market structure and confidently execute informed trading decisions.
Quarterly Theory ICT 01 [TradingFinder] XAMD + Q1-Q4 Sessions🔵 Introduction
The Quarterly Theory ICT indicator is an advanced analytical system based on the concepts of ICT (Inner Circle Trader) and fractal time. It divides time into quarterly periods and accurately determines entry and exit points for trades by using the True Open as the starting point of each cycle. This system is applicable across various time frames including annual, monthly, weekly, daily, and even 90-minute sessions.
Time is divided into four quarters: in the first quarter (Q1), which is dedicated to the Accumulation phase, the market is in a consolidation state, laying the groundwork for a new trend; in the second quarter (Q2), allocated to the Manipulation phase (also known as Judas Swing), sudden price changes and false moves occur, marking the true starting point of a trend change; the third quarter (Q3) is dedicated to the Distribution phase, during which prices are broadly distributed and price volatility peaks; and the fourth quarter (Q4), corresponding to the Continuation/Reversal phase, either continues or reverses the previous trend.
By leveraging smart algorithms and technical analysis, this system identifies optimal price patterns and trading positions through the precise detection of stop-run and liquidity zones.
With the division of time into Q1 through Q4 and by incorporating key terms such as Quarterly Theory ICT, True Open, Accumulation, Manipulation (Judas Swing), Distribution, Continuation/Reversal, ICT, fractal time, smart algorithms, technical analysis, price patterns, trading positions, stop-run, and liquidity, this system enables traders to identify market trends and make informed trading decisions using real data and precise analysis.
♦ Important Note :
This indicator and the "Quarterly Theory ICT" concept have been developed based on material published in primary sources, notably the articles on Daye( traderdaye ) and Joshuuu . All copyright rights are reserved.
🔵 How to Use
The Quarterly Theory ICT strategy is built on dividing time into four distinct periods across various time frames such as annual, monthly, weekly, daily, and even 90-minute sessions. In this approach, time is segmented into four quarters, during which the phases of Accumulation, Manipulation (Judas Swing), Distribution, and Continuation/Reversal appear in a systematic and recurring manner.
The first segment (Q1) functions as the Accumulation phase, where the market consolidates and lays the foundation for future movement; the second segment (Q2) represents the Manipulation phase, during which prices experience sudden initial changes, and with the aid of the True Open concept, the real starting point of the market’s movement is determined; in the third segment (Q3), the Distribution phase takes place, where prices are widely dispersed and price volatility reaches its peak; and finally, the fourth segment (Q4) is recognized as the Continuation/Reversal phase, in which the previous trend either continues or reverses.
This strategy, by harnessing the concepts of fractal time and smart algorithms, enables precise analysis of price patterns across multiple time frames and, through the identification of key points such as stop-run and liquidity zones, assists traders in optimizing their trading positions. Utilizing real market data and dividing time into Q1 through Q4 allows for a comprehensive and multi-level technical analysis in which optimal entry and exit points are identified by comparing prices to the True Open.
Thus, by focusing on keywords like Quarterly Theory ICT, True Open, Accumulation, Manipulation, Distribution, Continuation/Reversal, ICT, fractal time, smart algorithms, technical analysis, price patterns, trading positions, stop-run, and liquidity, the Quarterly Theory ICT strategy acts as a coherent framework for predicting market trends and developing trading strategies.
🔵b]Settings
Cycle Display Mode: Determines whether the cycle is displayed on the chart or on the indicator panel.
Show Cycle: Enables or disables the display of the ranges corresponding to each quarter within the micro cycles (e.g., Q1/1, Q1/2, Q1/3, Q1/4, etc.).
Show Cycle Label: Toggles the display of textual labels for identifying the micro cycle phases (for example, Q1/1 or Q2/2).
Table Display Mode: Enables or disables the ability to display cycle information in a tabular format.
Show Table: Determines whether the table—which summarizes the phases (Q1 to Q4)—is displayed.
Show More Info: Adds additional details to the table, such as the name of the phase (Accumulation, Manipulation, Distribution, or Continuation/Reversal) or further specifics about each cycle.
🔵 Conclusion
Quarterly Theory ICT provides a fractal and recurring approach to analyzing price behavior by dividing time into four quarters (Q1, Q2, Q3, and Q4) and defining the True Open at the beginning of the second phase.
The Accumulation, Manipulation (Judas Swing), Distribution, and Continuation/Reversal phases repeat in each cycle, allowing traders to identify price patterns with greater precision across annual, monthly, weekly, daily, and even micro-level time frames.
Focusing on the True Open as the primary reference point enables faster recognition of potential trend changes and facilitates optimal management of trading positions. In summary, this strategy, based on ICT principles and fractal time concepts, offers a powerful framework for predicting future market movements, identifying optimal entry and exit points, and managing risk in various trading conditions.
ICT SB Time (Lee B)A minimal and clean indicator that simply plots the ICT Silver Bullet time windows for you on the chart with vertical lines.
It also has the option to show other important times, like 00:00, 8:30, and 9:30. Toggles in settings let you change line color, turn any of them off temporarily, and can limit their visibility to only the lower timeframes for less clutter.
I hope you find this indicator useful... and happy trading!
Lee B
Multi-Asset & TF RSI
Multi-Asset & TF RSI
This indicator allows you to compare the Relative Strength Index (RSI) values of two different assets across multiple timeframes in a single pane. It’s ideal for traders who wish to monitor momentum across different markets or instruments simultaneously.
Key Features:
Primary Asset RSI:
The indicator automatically calculates the RSI for the chart’s asset. You can adjust the timeframe for this asset using a dropdown that offers standard TradingView timeframes, a "Chart" option (which syncs with your current chart timeframe), or a "Custom" option where you can enter any timeframe.
Optional Second Asset RSI:
Enable the “Display Second Asset” option to compare another asset’s RSI. Simply select the symbol (default is “DXY”) and choose its timeframe from an identical dropdown. When enabled, the second asset’s RSI is computed and plotted for easy comparison.
RSI Settings:
Customize the RSI length and choose the data source (e.g., close price) to suit your trading strategy.
Visual Aids:
Overbought (70) and oversold (30) levels are clearly marked, along with a midline at 50. These visual cues help you quickly assess market conditions.
Asset Information Table:
A dynamic table at the top of the pane displays the symbols being analysed – the chart’s asset as the “1st” asset and, if enabled, the second asset as the “2nd.”
How to Use:
Apply the Indicator:
Add the indicator to your chart. By default, it will calculate the RSI for the chart’s current asset using your chart’s timeframe.
Adjust Primary Asset Settings:
Use the “Main Asset Timeframe” dropdown to choose the timeframe for the RSI calculation on the chart asset. Select “Chart” to automatically match your current chart’s timeframe or choose a preset/custom timeframe.
Enable and Configure the Second Asset:
Toggle the “Display Second Asset” option to enable the second asset’s RSI. Select the asset symbol and its desired timeframe using the provided dropdown. The RSI for the second asset will be plotted if enabled.
Monitor the RSI Values:
Observe the plotted RSI lines along with the overbought/oversold levels. Use the table at the top-centre of the pane to verify which asset symbols are being displayed.
This versatile tool is designed to support multi-asset analysis and can be a valuable addition to your technical analysis toolkit. Enjoy enhanced RSI comparison across markets and timeframes!
Happy Trading!
ValueAtTime█ OVERVIEW
This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets.
█ CONCEPTS
UNIX timestamps
In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone .
This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars.
Storing and retrieving time-value pairs
This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:
• `times` – An array of "int" UNIX timestamps for each recorded value.
• `values` – An array of "float" values for each saved timestamp.
Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time .
Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:
1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.
2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp.
Value search methods
There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets:
Timestamp search
Find the value with the earliest saved timestamp closest to a specified timestamp.
Millisecond offset search
Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets.
Period offset search
Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:
• "D" for days
• "W" for weeks
• "M" for months
• "Y" for years
• "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone.
The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks).
Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year.
█ CALCULATIONS AND USE
This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs.
See below for explanations of the exported functions and how to use them.
Retrieving single values
The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:
• `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.
• `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.
• `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time.
Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp.
The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts.
Retrieving multiple values
The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:
• `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.
• `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.
• `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time.
Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts.
Processing period inputs
When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function.
This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input .
Calculating period offset times
Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case.
The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations.
For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone.
Collecting data
All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object.
For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID.
This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage.
The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals.
NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error.
█ EXAMPLE CODE
The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results.
The example code's process is as follows:
1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.
2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.
3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.
4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone.
█ NOTES
• This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.
• The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .
• Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .
• Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars.
Look first. Then leap.
█ EXPORTED TYPES
Data
A structure for storing successive timestamps and corresponding values from a dataset.
Fields:
times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.
values (array) : A "float" array containing values corresponding to the timestamps in the `times` array.
█ EXPORTED FUNCTIONS
getArrayFromString(str)
Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.
Parameters:
str (series string) : The "string" to split into an array based on its commas.
Returns: (array) An array of trimmed substrings from the specified `str`.
periodToTimestamp(period, referenceTime)
Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.
Parameters:
period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.
Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`.
collectData(source, timeOffsetLimit, timeframeLimit)
Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range.
method valueAtTime(data, timestamp)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the specified `timestamp` ("int").
valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the specified `timestamp` ("int").
- The current bar's `source` value ("float").
method valueAtTimeOffset(data, timeOffset)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
- The current bar's `source` value ("float").
method valueAtPeriodOffset(data, period)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int").
valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int").
- The current bar's `source` value ("float").
getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each item in the `timestamps` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each period specified in the `periods` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
Price and Longitude Angles Planetary Price & Longitude Angles Indicator
This indicator plots planetary price and longitude angles starting from a user-selected date and time, offering a distinctive lens to explore the relationship between price and planetary timing. It supports both heliocentric and geocentric, enabling flexible and in-depth planetary analysis. The angles can be plotted across any time frame for maximum versatility.
How to Use
Once the indicator is loaded, you’ll be prompted to select a starting date and time for your analysis. From there, customize it as follows:
Select Planetary Options:
To plot the price and longitude for a single planet, choose the same planet in both dropdown menus.
To plot the average of two planets, select a different planet in each dropdown.
Set the Price Per Degree of Longitude: Adjust this value to define the scaling of the planetary angles relative to price.
Customize Fan Settings:
Toggle the mirroring of the fan on or off based on your needs.
Show or hide specific angle divisions to tailor the display to your preferences.
Display or conceal the information label that indicates the price per longitude and the number of degrees traveled.
This indicator is inspired by the methodologies of W.D. Gann and Patrick Mikula, expanding on concepts from Gann Scientific Method Unveiled, Volume 2. It was built using Astrolib by @BarefootJoey
I crafted this tool through dedication to support my own study of these ideas. I’m sharing it open-source not only to deepen my understanding and honor the work of Gann and Mikula, but also to invite collaboration. There’s always room for improvement—whether in functionality, accuracy, or design—and I hope others will join me in refining it. This is for those like me: eager to explore these concepts but lacking tools to experiment with. Let’s build on it together.
Time-based Alerts for Trading Windows🌟 Time-based Alerts for Trading Windows 🌐📈
This is a re-uploaded script as the previous one got hidden.
This Time-based Alerts for Trading Windows script is a highly customizable and reliable tool designed to assist traders in managing automated strategies or manually monitoring specific market conditions. Inspired by CrossTrade's Time-based Alert, this script is tailored for those who rely on precise time windows to trigger actions, such as sending webhook signals or managing Expert Advisors (EAs).
Whether you are a scalper, day trader, or algorithmic trader, this script empowers you to stay on top of your trades with fully customizable time-based alerts.
🛠️ Customizable Time Alerts
This indicator allows you to create up to 12 unique time windows by specifying the exact hour and minute for each alert. Each time window corresponds to an individual alert condition, making it perfect for managing trades during specific market sessions or key time periods.
For example:
Alert 1 can be set at 9:30 AM (market open).
Alert 2 can be set at 3:55 PM (just before market close).
Each alert can be toggled on or off in the indicator settings, allowing you to manage alerts without having to reconfigure your script.
You can adjust the colours to fit any colour scheme you like!
🕒 Odd and Even Time Alerts
The script comes with three built-in alert type categories:
Odd Alerts (marked with a green triangle on the chart): These correspond to odd-numbered inputs like Alert 1, Alert 3, Alert 5, and so on.
Even Alerts (marked with a red triangle on the chart): These correspond to even-numbered inputs like Alert 2, Alert 4, Alert 6, and so on.
You can also customize all 12 alerts individually to include a custom alert message
These alerts serve as a convenient way to differentiate between multiple trading strategies or market conditions. You can customize alert messages for odd and even alerts directly from TradingView’s alert panel.
🔗 Webhook Integration for Automation
This script is fully compatible with webhook-based automation. By configuring your alerts in TradingView, you can send signals to trading bots, EAs, or any third-party system. For example, you can:
Turn off an EA at a specific time (e.g., 3:55 PM EST).
Send buy/sell signals to your bot during predefined trading windows.
Simply use TradingView’s alert message editor to format webhook payloads for your automation system.
🌐 Timezone Flexibility
Trading happens across multiple time zones, and this script accounts for that. You can toggle between:
Eastern Time (New York): Ideal for most US-based markets.
Central Time (Exchange): Useful for futures and commodities traders.
This ensures your alerts are always in sync with your preferred time zone, eliminating confusion.
🎨 Visual Indicators
The script plots visual markers directly on your chart to indicate active alerts:
Up Facing Triangles: Represent odd-numbered alerts, providing a quick reference for these time windows.
Down Facing Triangles: Represent even-numbered alerts, helping you track different strategies or conditions.
These visual markers make it easy to see when alerts are triggered, even at a glance.
📈 Practical Use Case
Let’s say you’re trading the USTEC index on a 1-minute chart. You want to:
Turn off your trading bot at 16:55 EST to avoid after-market volatility.
Trigger a re-entry signal at 17:30 EST to capture moves during the Asian session.
Visually monitor these actions on your chart for easy reference.
This script makes it possible with precision alerts and webhook integration. Simply configure the time windows in the settings and set up your alerts in TradingView.
🚨 How to Set Up Alerts
Enable or Disable Alerts: Use the script’s settings to toggle specific alerts on or off as needed.
Set Custom Time Windows: Define the hour and minute for each alert in the settings panel.
Create Alerts in TradingView:
Go to the TradingView alert panel.
Select the condition (e.g., "Odd Time-based Alert (Green)" or "Even Time-based Alert (Red)").
Customize the alert message for webhook integration or personal notification.
Choose the trigger type: Once Per Bar or Once Per Bar Close to keep the alert active.
Integrate with Webhooks: Use the alert message field to format payloads for automation systems like MT4, MT5, or third-party bots.
📋 Key Notes
Alerts can trigger indefinitely if set to "Once Per Bar" or "Once Per Bar Close".
Always ensure the expiration date is set far in the future to avoid unexpected alert deactivation.
Test webhook messages and alert configurations thoroughly before using them in live trading.
This script is a powerful addition to your trading toolbox, offering precision, flexibility, and automation capabilities. Whether you’re turning off an EA, managing trades during market sessions, or automating strategies via webhooks, this script is here to support you.
Start using the Time-based Alerts for Trading Windows today and trade with confidence! 🚀✨
Vertical Line Timeline by SymphonyTraderThis indicator will allow you to plot 5 different vertical lines for a time that you specify, including intervals less than 1 hour.
For example, for 9:00 am you would use 9 and for 9:30 am you would use 9.5.
It also has a Timezone offset, so that you can completely customize the indicator to match what timezone you have displayed on your charts.
Hybrid Triple Exponential Smoothing🙏🏻 TV, I present you HTES aka Hybrid Triple Exponential Smoothing, designed by Holt & Winters in the US, assembled by me in Saint P. I apply exponential smoothing individually to the data itself, then to residuals from the fitted values, and lastly to one-point forecast (OPF) errors, hence 'hybrid'. At the same time, the method is a closed-form solution and purely online, no need to make any recalculations & optimize anything, so the method is O(1).
^^ historical OPFs and one-point forecasting interval plotted instead of fitted values and prediction interval
Before the How-to, first let me tell you some non-obvious things about Triple Exponential smoothing (and about Exponential Smoothing in general) that not many catch. Expo smoothing seems very straightforward and obvious, but if you look deeper...
1) The whole point of exponential smoothing is its incremental/online nature, and its O(1) algorithm complexity, making it dope for high-frequency streaming data that is also univariate and has no weights. Consequently:
- Any hybrid models that involve expo smoothing and any type of ML models like gradient boosting applied to residuals rarely make much sense business-wise: if you have resources to boost the residuals, you prolly have resources to use something instead of expo smoothing;
- It also concerns the fashion of using optimizers to pick smoothing parameters; honestly, if you use this approach, you have to retrain on each datapoint, which is crazy in a streaming context. If you're not in a streaming context, why expo smoothing? What makes more sense is either picking smoothing parameters once, guided by exogenous info, or using dynamic ones calculated in a minimalistic and elegant way (more on that in further drops).
2) No matter how 'right' you choose the smoothing parameters, all the resulting components (level, trend, seasonal) are not pure; each of them contains a bit of info from the other components, this is just how non-sequential expo smoothing works. You gotta know this if you wanna use expo smoothing to decompose your time series into separate components. The only pure component there, lol, is the residuals;
3) Given what I've just said, treating the level (that does contain trend and seasonal components partially) as the resulting fit is a mistake. The resulting fit is level (l) + trend (b) + seasonal (s). And from this fit, you calculate residuals;
4) The residuals component is not some kind of bad thing; it is simply the component that contains info you consciously decide not to include in your model for whatever reason;
5) Forecasting Errors and Residuals from fitted values are 2 different things. The former are deltas between the forecasts you've made and actual values you've observed, the latter are simply differences between actual datapoints and in-sample fitted values;
6) Residuals are used for in-sample prediction intervals, errors for out-of-sample forecasting intervals;
7) Choosing between single, double, or triple expo smoothing should not be based exclusively on the nature of your data, but on what you need to do as well. For example:
- If you have trending seasonal data and you wanna do forecasting exclusively within the expo smoothing framework, then yes, you need Triple Exponential Smoothing;
- If you wanna use prediction intervals for generating trend-trading signals and you disregard seasonality, then you need single (simple) expo smoothing, even on trending data. Otherwise, the trend component will be included in your model's fitted values → prediction intervals.
8) Kind of not non-obvious, but when you put one smoothing parameter to zero, you basically disregard this component. E.g., in triple expo smoothing, when you put gamma and beta to zero, you basically end up with single exponential smoothing.
^^ data smoothing, beta and gamma zeroed out, forecasting steps = 0
About the implementation
* I use a simple power transform that results in a log transform with lambda = 0 instead of the mainstream-used transformers (if you put lambda on 2 in Box-Cox, you won't get a power of 2 transform)
* Separate set of smoothing parameters for data, residuals, and errors smoothing
* Separate band multipliers for residuals and errors
* Both typical error and typical residuals get multiplied by math.sqrt(math.pi / 2) in order to approach standard deviation so you can ~use Z values and get more or less corresponding probabilities
* In script settings → style, you can switch on/off plotting of many things that get calculated internally:
- You can visualize separate components (just remember they are not pure);
- You can switch off fit and switch on OPF plotting;
- You can plot residuals and their exponentially smoothed typical value to pick the smoothing parameters for both data and residuals;
- Or you might plot errors and play with data smoothing parameters to minimize them (consult SAE aka Sum of Absolute Errors plot);
^^ nuff said
More ideas on how to use the thing
1) Use Double Exponential Smoothing (data gamma = 0) to detrend your time series for further processing (Fourier likes at least weakly stationary data);
2) Put single expo smoothing on your strategy/subaccount equity chart (data alpha = data beta = 0), set prediction interval deviation multiplier to 1, run your strat live on simulator, start executing on real market when equity on simulator hits upper deviation (prediction interval), stop trading if equity hits lower deviation on simulator. Basically, let the strat always run on simulator, but send real orders to a real market when the strat is successful on your simulator;
3) Set up the model to minimize one-point forecasting errors, put error forecasting steps to 1, now you're doing nowcasting;
4) Forecast noisy trending sine waves for fun.
^^ nuff said 2
All Good TV ∞
Weekly Stacked Daily Changes [LuxAlgo]The Weekly Stacked Daily Changes tool allows traders to compare daily net price changes for each day of the week, stacked by week. It provides a very convenient way to compare daily and weekly volatility at the same time.
🔶 USAGE
The tool requires no configuration and works perfectly out of the box, displaying the net price change for each day of the week as stacked boxes of the appropriate size.
Traders can adjust the width of the columns and the spacing between days and weeks, options to change the color and disable the months and new month lines are also available.
🔹 Bottom Stack Bias
This feature allows traders to compare weekly volatility in two different ways.
With this feature disabled, all weeks use zero as the bottom of the stack, so traders can see at a glance weeks with more volatility and weeks with less volatility.
Enabling this feature will cause the tool to display the stacks with the weekly net price change as the bottom, so if a stack starts below the zero line it means that week has a negative net return, and if it starts above the zero line it means that week has a positive net return.
🔶 SETTINGS
Width: Select the fixed width for each column.
Offset: Choose the fixed width between each column.
Spacing: Select the distance between each day within each column.
🔹 Style
Bottom Stack Bias: Use weekly net price change as the bottom of the stack.
Bullish Change: Color for days with positive net price change
Bearish Change: Color for days with negative net price change
Show Months: Under each week stack, display the month
Show Months Delimiter: Display a line indicating the start of a new month
Dynamic Time Period CandlesThis indicator gives the dynamic history of the current price over various time frames as a series of candles on the right of the display, with optional lines on the chart, so that you can assess the current trend more easily.
In the library I found lots of indicators that looked at the previous xx time period candle, but they then immediately switched to the new xx time candle when it started to be formed. This indicator looks back at the rolling previous time period. With this indicator, you can clearly see how price has been behaving over time.
IMPORTANT SETUP INFO:
Initially, you must go into the settings and select the timeframe (in minutes) that your chart is displaying. If you don't do this then the indicator will look back the wrong number of candles and give you totally wrong results.
You can then setup how high you want the candle labels to be on the chart.
Then you can select settings for each candle that you want displayed. Anywhere between 1 and 5 different timeframes can be displayed on the chart at once.
I initially published an indicator called 'Dynamic 4-Hour Candle (Accurate Highs and Lows)', but this new indicator is so different that it needs to be forked and published as a separate indicator. The reasons for this are below:
The original indicator only looked at the previous 4 hour time period. This indicator allows the user to select any time period that they choose.
The original indicator only looked at one time period. This indicator allows to select between one and five time periods on the chart at once.
The original indicator did not put lines on the chart to show the lookback period and the highs and lows of that time period. This indicator does both those things.
The name of the original indicator in no way now describes what this new indicator is capable of, and would be very misleading to anyone who came across it. This new indicator has a name that much more accurately reflects what its' purpose and functionality is.
Multi-Timeframe Period Separators█ OVERVIEW
This indicator plots period separators for up to four higher timeframes. The separators are fully customizable and designed to work on any symbols.
█ FEATURES
Reference
You can choose to plot the separators starting from midnight 00:00 or the opening of the exchange trading session.
Timezone
You can specify to localize midnight 00:00 to the region of your liking. The timezone format conveniently requires no manual adjustment during clock changes.
█ NOTES
Scans the bar opening and closing times
The script checks the bar ` time ` and ` time_close ` to pinpoint the separators that can occur intrabar.
Tracks from the last separator
The script tracks the time elapsed since the last separator, which is useful when there is no trading activity or the market is closed. As it can result in missing bars, it plots the separator on the first available bar.
Others
The script automatically hides the separators when navigating to an equal or higher chart timeframe.
