Pine Script Timestamps: How to Use Time Functions in TradingView
Pine timestamps are integer counts of milliseconds since the UNIX epoch, 1970-01-01 00:00:00 UTC. They identify instants independently of timezone. The distinction between bar time, session time and script execution time determines whether a time filter behaves consistently in historical and realtime calculations.
Choose the Correct Time Value
| Pine identifier | Meaning |
|---|---|
time | Opening timestamp of the current chart bar |
time_close | Closing timestamp of the chart bar, where available |
timenow | Timestamp of the script's current execution |
time() | Function that can calculate bar-opening times for a timeframe and session |
time_close() | Corresponding function for bar-closing times |
timestamp() | Constructs a timestamp from a date/time specification |
The first three are built-in variables; timenow() is not the correct call syntax. time() is not simply a zero-argument replacement for time. TradingView's time documentation describes their signatures and behavior.
On time-based charts, a bar's scheduled closing timestamp may be known before the bar is complete. It is not proof that the bar has closed or that a strategy has executed. On open realtime bars of some non-time-based charts, the closing time cannot be predicted and can be unavailable.
Timestamps Are Not Timezones
Formatting the same timestamp in UTC and New York produces different clock labels for the same instant. Neither representation is wrong if the intended timezone is explicit. Use str.format_time() with a declared timezone for readable debugging output.
Calendar functions such as year(), month(), hour() and minute() extract components from a timestamp. Without an explicit timezone, relevant calendar calculations generally use the exchange timezone, not the chart's display timezone. Record the symbol, session and timezone in any test.
Use IANA identifiers such as America/New_York and Europe/London for rules tied to those local clocks. Fixed UTC offsets do not automatically adjust for daylight-saving changes. Changing a chart's display setting does not necessarily change the script's timing rule.
Milliseconds, Durations and Calendar Dates
If an external value is in seconds, convert its units before comparing it with a Pine timestamp. A difference between two Pine timestamps is in milliseconds. Document units in variable names or comments to avoid a thousandfold timing error.
Adding a fixed number of milliseconds describes elapsed time. It does not always describe the same local-clock time on the next calendar day across daylight-saving transitions. If the rule is calendar-based, construct the desired date and time in its intended timezone instead of assuming every civil day has the same duration.
Historical Bar Time Versus Execution Time
During a historical recalculation, timenow reflects when the script runs, not when each historical bar originally traded. It is unsuitable as a replacement for historical bar time in a backtest date filter.
It is also not an independent timer that wakes the script continuously. A script must execute for the value to be observed. An alert intended for an exact clock time can be delayed until a relevant data update, and a strategy's calculation settings further affect when its conditions are evaluated.
Use bar timestamps for reproducible historical conditions, then separately define alert frequency and order timing. TradingView's execution model explains why the same bar can have multiple realtime updates.
Date Ranges and Recurring Sessions Are Different Inputs
input.time() selects a timestamp. A bounded date-range filter needs separate start and end values plus a stated boundary convention, such as including bars whose opening time is at or after the start and before the end. Interactive confirmation does not make one timestamp a recurring daily window.
For a recurring session, use session membership and an explicit timezone. time() can return a timestamp for an in-session bar and na outside the selected session. A session's boundaries must align with the chart interval if the calculation uses full chart-bar OHLC. The session documentation covers these details.
A London-local 08:00 opening is not a fixed 08:00 UTC event throughout the year. Session strings also do not create a holiday calendar or invent bars during a closure.
Higher-Timeframe Boundaries
A higher-timeframe opening or closing timestamp does not certify that its price data is confirmed. time_close does not become the current bar's opening time merely because that bar is still developing. It remains a closing-time value where known.
When requesting higher-timeframe prices, specify whether the rule uses developing or completed values. Timestamp alignment alone cannot prevent future leakage or realtime changes. See other timeframes and data.
For a first bar of a monthly period, distinguish a timeframe-period change from a comparison of calendar month numbers. A calendar comparison should include the year when gaps can cross years, and the first loaded bar may be a partial period rather than the actual period open.
A Practical Debugging Checklist
Inspect the chart bar's opening time, expected closing time, selected timezone and session membership for the same observations. Check a normal day, a weekend, a daylight-saving transition and a shortened session. Test a history window beginning midway through a session.
If using Pineify to draft a time filter, state these requirements explicitly and inspect the generated code. Do not assume every calendar function has a dedicated visual control or that an AI-generated condition matches the intended timezone without review.
For trading rules, record whether the timestamp condition permits an order to be submitted or requires a position to be closed. The latter also needs an order and fill policy. A time comparison alone does not guarantee execution at the requested instant.