Time Stops in Trading: Count Bars or Elapsed Minutes?

“Close the trade after six bars” sounds precise until someone changes the chart timeframe. Six five-minute bars and six hourly bars give a trade very different amounts of breathing room. A session break adds another complication: the clock keeps moving while the chart may produce no bars at all.

A time stop is an exit condition based on holding duration. It needs a starting event, a unit and an evaluation schedule. In automated trading, the moment that condition becomes due is also separate from the moment an exit fills. For an AlgoWay workflow, use the strategy alert timing guide to distinguish the simulated trade event, outgoing alert and account execution when checking the result. This article defines the strategy rule; it does not assume a built-in account-side timeout setting.

Choose what the timer measures

Three reasonable specifications answer three different questions:

• Bar count: how many chart bars have completed since entry? Useful when the idea is expressed in successive price observations.
• Elapsed time: how many minutes have passed since the chosen entry timestamp? Overnight and weekend intervals count unless you explicitly remove them.
• Trading-session time: how many eligible market minutes have passed? This needs a session calendar and a defined treatment of breaks, rather than simple timestamp subtraction.

These are design choices, not interchangeable implementations. Suppose a hypothetical market trades from 09:30 to 16:00, and an entry occurs at 15:50. A thirty-minute elapsed deadline is 16:20 that day. Six completed five-minute bars, counting the entry bar as the first, finish at 09:50 in the next session if no bars occur outside those hours. The same advertised “thirty-minute exit” could therefore describe radically different exposure.

If the rule must avoid holding overnight, specify a separate session-end policy. A timer that becomes due after the market closes cannot retroactively execute before the close. See the session timezone and boundary guide for the calendar side of that policy.

Start at the fill, or deliberately choose something else

A signal timestamp, an entry-order submission timestamp and an entry-fill timestamp can differ. A limit order could wait before entry. Counting from its submission would consume some of the supposed holding period while there was no position to hold.

For a holding-duration rule, a sensible specification is “start at the entry fill.” In a Pine backtest, public functions such as strategy.opentrades.entry_time() and strategy.opentrades.entry_bar_index() provide simulated entry information; they are documented in TradingView's individual trade information reference. They do not establish a downstream broker's actual fill time.

With multiple entries, also decide whether each entry has its own timer or whether the whole position uses the oldest entry's deadline. Resetting the entire position's clock whenever size is added is a third policy. Write it down: otherwise a late addition can quietly grant an old trade a new lease on life.

The entry bar is the usual counting trap

Assume a simulated fill at the 10:00 open of a five-minute bar, numbered 100. At its 10:05 close, one bar has completed while the position was held, but the current bar index minus the entry bar index is zero.

At the close of bar 105, at 10:30, six bars including the entry bar have completed. Yet the index difference is only five. A condition requiring an index difference of at least six first becomes true at the close of bar 106, at 10:35, under this bar-close evaluation schedule.

Neither convention is inherently forbidden. They simply need different names. “Six completed bars including the entry bar” differs from “an index distance of six.” If entry occurs partway through a bar, counting that bar as a full holding interval is another explicit approximation.

A deadline is not an independent alarm clock

TradingView's time-delay FAQ explains that time conditions are checked when the strategy executes. Under default bar-close calculation, a deadline between bar closes is detected at a later evaluation. No price updates during a market closure also mean no opportunity to evaluate the rule there.

For example, an entry timestamp of 10:02 plus thirty minutes gives a 10:32 deadline. A strategy evaluating five-minute bar closes would first see that deadline reached at 10:35, assuming uninterrupted bars and no extra recalculations. The order still needs to be created and filled. Pine's default broker-emulator behavior fills a newly created market order on the next available tick, usually the following bar's open under default calculation. Order-processing settings can change that simulation; they do not guarantee a live account fill at the deadline.

Pine's time is the bar-open timestamp; time_close is the bar-close timestamp. Using bar-open time in a close-evaluated duration check can delay the condition by a bar. Also, timenow records script execution time, not a historical bar's clock. It is not a suitable substitute for historical elapsed-time calculations and does not wake a script up by itself. These distinctions are documented in the Pine time reference.

Check the boundary cases before sending exit alerts

Record the entry fill, chosen deadline, first eligible evaluation, exit request and exit fill separately. Check an entry at a bar open, an intrabar entry, an entry just before a session break and a position receiving an additional entry. Repeat after changing chart timeframe: a minute-based deadline should retain its intended duration, while a bar-count rule should change with the bars.

Finally, decide what happens if a protective exit closes the trade before the timer expires. The timeout must act on the remaining live position, not on a stale assumption that the original quantity is still open. Choosing the appropriate Pine close command is a separate step covered in strategy.close versus strategy.exit. A time stop limits patience according to a rule; it does not cap the price loss that can occur while waiting.