Pine Script Session & Timezone Tool

A session string has two segments. The first is a pair of times in twenty-four hour form with no colon, separated by a hyphen, so half past nine in the morning until four in the afternoon is written 0930-1600. The second segment is optional and lists which days the session applies to, separated from the times by a colon. Weekdays only becomes 0930-1600:23456.

The day numbering is the part that catches everyone. Pine counts from one to seven starting at Sunday, so Monday is 2 and Friday is 6. Most other systems either start at Monday or count from zero, which means a session string copied from another platform or written from memory is very often shifted by one day. The symptom is subtle: the filter works, it just admits Sunday and excludes Friday, and on a market that does not trade Sunday you may not notice for a long time.

When the times are equal, Pine treats the session as covering the whole day, which is how a twenty-four hour crypto session is expressed. When the end time is earlier than the start time, the session runs through midnight into the following day, which is normal for futures and worth being deliberate about, because a session that spans midnight also spans a day boundary in the day segment.

Session strings are not evaluated in your timezone. Unless you say otherwise, they are interpreted in the exchange's timezone, which is what syminfo.timezone reports for the current symbol. This is almost always the behaviour you want, because market hours are a property of the market rather than of whoever is looking at the chart. It is also why a filter that appears to be an hour or five hours out is usually not broken at all: it is doing exactly what you asked, in a timezone you did not think about.

The conversion table above exists to make that concrete. If you are in London looking at a US equity, the regular session opens at half past two in the afternoon your time, and your intuition about what a nine-thirty filter means is not going to help you read the chart. Worse, the offset is not constant: the US and Europe change their clocks on different dates, so for a couple of weeks each year the gap is an hour different from the rest of the year. Writing the filter against exchange time sidesteps the whole problem, because the exchange is the thing whose hours you actually care about.

Passing syminfo.timezone explicitly as the third argument to time() is worth doing even though it matches the default. It documents the decision, and it means a reader does not have to know the default to understand the code. Hardcoding a specific zone such as America/New_York is occasionally correct, but only when you genuinely mean that zone regardless of the symbol on the chart, which is rarer than it seems.

The mechanism is easy to miss because it hides inside a function that looks like it returns a time. time(timeframe.period, session, timezone) returns the bar's timestamp when the bar falls inside the session, and na when it does not. The filter is therefore not a comparison but a test for absence: not na(...) is what turns that into a boolean you can combine with your own conditions.

Once you have that boolean, the transitions come for free. A bar where the session is active and the previous bar's was not is the session open, and the reverse is the close. Those two are usually what an intraday rule actually wants, because entering on every bar inside a window is a different rule from entering when the window begins.

One caveat about timeframes. A session filter is meaningful on intraday charts. On a daily or higher timeframe, a bar covers the whole session, so filtering by hours has no useful effect and a script that depends on it will behave in ways that look like a bug. If a filtered strategy produces identical results on daily bars regardless of the session, that is why.