Skip to main content
On this page

Pine Script Timeframe Input: Build Flexible Indicators with input.timeframe

· 5 min read
Pineify Team
Pine Script and AI trading workflow research team
Pineify | Best Pine Script Editor

input.timeframe() creates a timeframe selector and returns a string. It does not fetch data, change the chart timeframe or prevent repainting. The consuming calculation determines which data is requested and when that data becomes available.

Use Pine Timeframe Strings​

Intended intervalPine string
Five minutes"5"
Fifteen minutes"15"
One hour"60"
Four hours"240"
One day"1D"
One week"1W"
One month"1M"

Minutes have no unit letter; Pine does not use "1h" or "5m" for those intervals. Uppercase M means months. TradingView's timeframe documentation specifies valid strings and multipliers.

Configure the Input​

defval supplies the initial value, title labels the control, and options restricts the allowed choices. If options are provided, include the default in that list. A tooltip should explain whether the script accepts lower, equal or higher timeframes.

inline arranges related controls on the same row; group groups inputs under a heading. confirm asks users to configure inputs when adding the script, rather than acting as a safety confirmation for every later timeframe switch. See TradingView's input documentation.

Changing an input causes the script to recalculate over the dataset. An existing alert retains its saved context; recreate it when its relevant settings change.

Pineify | Best Pine Script Generator

A Complete Confirmed Higher-Timeframe Example​

This indicator accepts only a timeframe strictly above the chart's interval. It plots the close and 20-period SMA from the previous completed higher-timeframe bar.

//@version=6
indicator("Confirmed higher-timeframe values", overlay = true)
string selectedTimeframe = input.timeframe("1D", "Higher timeframe", options = ["60", "240", "1D", "1W", "1M"], tooltip = "Choose a timeframe strictly above the chart timeframe")
if timeframe.in_seconds(selectedTimeframe) <= timeframe.in_seconds()
runtime.error("The selected timeframe must be higher than the chart timeframe")
[confirmedClose, confirmedSma] = request.security(syminfo.tickerid, selectedTimeframe, [close[1], ta.sma(close, 20)[1]], lookahead = barmerge.lookahead_on)
plot(confirmedClose, "Previous completed HTF close", color = color.blue)
plot(confirmedSma, "Previous completed HTF SMA 20", color = color.orange)

On a five-minute chart with one day selected, the displayed values belong to the previous completed daily bar. The twenty-period SMA is calculated in the requested daily context, not over twenty five-minute bars after the data is mapped.

The two expressions share one tuple request. Their one-bar offsets are inside the requested context, and lookahead_on maps those already-known values from the beginning of the next higher-timeframe period. The delay is intentional: the current daily close is not yet final.

Why lookahead_off Is Not a Complete Repainting Fix​

Current Pine requests default to lookahead_off. That avoids one form of historical future leakage but still allows a developing higher-timeframe value to change in realtime. After reload, historical bars can display a different update pattern.

Conversely, lookahead_on without the appropriate historical offset can leak future higher-timeframe values into earlier historical bars. The combination matters. The example follows TradingView's documented confirmed higher-timeframe request pattern; it does not claim every script using the flag is safe.

Do not remove the higher-timeframe guard and assume this becomes a general lower-timeframe collector. request.security() on a lower timeframe does not provide every intrabar. Use request.security_lower_tf() when the task needs an array of intrabar observations, and define how those observations are aggregated.

Verification Steps​

  1. Start on a standard five-minute chart and select a daily interval.
  2. Compare the displayed close with the previous completed daily candle on the same symbol and session context.
  3. Observe the value during a developing day: it should not follow the current daily close.
  4. Reload and compare the observations around daily boundaries.
  5. Select a timeframe equal to or below the chart and confirm the explicit error.

A compilation check verifies syntax, not every feed, session or runtime scenario. Corporate-action adjustments and data revisions can also change historical series independently of this timing pattern.

Resource Limits and Design Choices​

There is no universal three-request limit. TradingView limits unique request calls and other resources, with some limits depending on the plan. Identical requests can be reused, while distinct symbols, timeframes or arguments can create separate requests. Check the current limitations page for the environment you intend to support.

Use tuples when calculations genuinely share a context. Do not combine unrelated requests merely to make the code shorter, and do not promise an unlimited symbol or timeframe scanner because the selector is flexible.

Frequently Asked Questions​

Does input.timeframe change the chart interval?
No. It returns a chosen timeframe string for the script to use.
Can I use this in a strategy?
Yes, but the strategy must still define order timing and ensure requested data was available when each decision occurred.
Why is the example one higher-timeframe bar behind?
It uses a completed value. The current higher-timeframe close is still developing and cannot be treated as final.
Is lookahead_on always wrong?
No. With a suitable prior-bar expression in a strictly higher-timeframe request, it can map confirmed data consistently. Without that offset it can introduce historical future leakage.
Does a timeframe selector improve win rate?
The input is a user-interface feature. No 80%-to-55% test or other performance comparison is established here.