图表的时区设置如何影响脚本行为

在使用TradingView内置的日期和时间变量时，为什么将图表时区设置为‘Exchange’（交易所）非常重要？下面我们来看几个例子。

范例1：为日历天的第一根价格K线上色

下面的这个范例指标会检查当前的价格K线是否为当天的第一根，如果是，则为该K线的背景上色。当K线不是当天的第一根时，我们使用 na 变量来使背景变为透明。

通过这种方式，我们可以预期每天只有第一根K线会拥有彩色的背景。尽管这个范例只有短短几行，但我们在更复杂的脚本中也会使用相同的逻辑（例如，交易开盘跳空或追踪每日高低点）。

为当天第一根K线的背景上色的代码如下：

//@version=5
indicator(title="Recipe - First bar of day", overlay=true)

// 当当前K线的日期（几号）不同于
// 前一根K线的日期时，当前K线即为
// 当天的第一根K线
firstBar = dayofmonth != dayofmonth[1]

// 确定背景颜色
colourOfBg = firstBar ? color.teal : na

// 执行背景上色操作
bgcolor(color.new(colourOfBg, 90))

当我们将这个范例添加到一个设置为‘Exchange’（交易所）时区的原油差价合约（Crude Oil CFD）图表上时，图表看起来是这样的：

在这里，脚本的行为符合预期：被高亮的K线与水平时间轴上的日期标记完全吻合。也就是说，标记着该月7号、8号、9号和10号的K线，其背景颜色都被设置为了青色。

现在，当我们将图表的时区设置更改为UTC+1时，图表看起来是这样的：

如果我们只考虑价格行为本身，那么被高亮的仍然是同样的那几根K线。这是因为 dayofmonth 变量是基于交易所的时区来工作的，这个基准并不会因为我们调整了图表的显示时区而改变。

真正改变的是图表的时间轴发生了多大的偏移。现在，如果我们观察图表的时间轴，会发现被高亮的K线已经不再对应于每日的第一根K线了。相反，每日的第一根K线现在看起来像是在一天开始几小时后才出现。如果我们不明就里，很可能会认为这个脚本出了问题。而如果脚本需要根据每日第一根K线进行交易，我们就会惊奇地发现交易都在错误的时间发生了。

范例2：高亮特定交易时段内的价格K线

在第二个范例指标中，我们以编程方式来判断一根价格K线是否落入一个特定的交易时段内。如果是，我们就为图表的背景上色。通过这种方式，该指标会将发生在9:30到16:00之间的所有价格K线的背景都进行上色。实现此功能的代码如下：

//@version=5
indicator(title="Recipe - Highlight a trading session", overlay=true)

// 每当 `time()` 函数返回一个非 `na` 的值时，
// 就意味着当前K线落入该时段内。此时我们的 
// `inSession` 变量为 `true`。
inSession = not na(time(timeframe.period, "0930-1600")[1])

// 当K线落在时段内时将颜色设置为 color.orange，
// 否则为 `na` (即没有颜色)
colourOfBg = inSession ? color.orange : na

// 为图表背景上色
bgcolor(color.new(colourOfBg, 85))

当这个范例指标被添加到一个时区设置为‘Exchange’（交易所）的AUD/CAD 30分钟图表上时，它看起来是这样的：

在这里我们可以看到，脚本从9:30的K线开始，将背景涂成橙色，一直持续到16:00的K线（包含16:00这根）。通过这种方式，指标正确地识别出了在该时间段内发生的所有价格行为。

现在，如果我们将图表的时区从UTC-5（AUD/CAD的交易所时间）调整到UTC+3，图表会变为：

同样，如果我们只关注价格行为本身，那么被高亮的仍然是同样的那几根K线。这是因为 time() 函数是基于该交易品种的交易所时区来工作的，而当我们进行视觉上的图表调整时，交易品种本身的报价时区并未改变。

但是，观察K线的时间戳，水平时间轴现在显示的是18:00到00:00之间的K线拥有橙色背景。如果我们没有考虑到哪些TradingView函数和变量是使用‘Exchange’（交易所）时间来工作的，我们很可能会认为自己的脚本中存在编程错误，或者TradingView的某个地方有bug。但事实上，脚本的行为完全符合其设计初衷。

注意事项

当我们使用一个不同于‘Exchange’的时区时，我们的指标或策略仍然在正确地工作——尽管从图表上显示的时间来看，情况似乎并非如此。为了避免混淆和花费大量时间去寻找本不存在的编程错误，请考虑始终在你的所有图表上使用‘Exchange’（交易所）时区设置。

注意事项

我们也可以利用“TradingView脚本是基于交易品种的时区而非图表显示时区进行计算”这一事实。例如，假设我们为图表上某个特定的时间范围上色（如前例所示）。如果我们之后更改图表的显示时区，我们便可以轻松地看出交易所时间是如何对应于那个其他时区的。

TradingView的变量和函数使用哪个时区

当你在指标或策略中使用内置的时间和日期变量或函数时，一个绕不开的问题是：返回的值究竟基于哪个时区？

探讨：TradingView函数和变量所使用的时区

当我们在代码中使用时间和日期时，尤其是在像TradingView这样的全球化平台上，我们不可避免地会遇到处理不同时区的问题。

除了我们图表本身的显示时区，我们还必须留意函数和变量本身使用的是哪个时区。这样，当我们的脚本行为与预期不符时，我们就能排查这是否是由时区设置引起的。

标准的TradingView变量和函数主要使用两种时区之一进行工作：交易品种的交易所时区，或UTC（协调世界时）时区。

使用交易所时区的函数和变量

为了使TradingView脚本的行为标准化，几乎所有内置的时间和日期变量及函数，都以与当前交易品种相同的时区来返回它们的值。

这意味着大多数内置变量和函数并不会理会我们价格图表的显示时区，而是以图表上交易品种自身的时区来返回值。当这个时区与图表的显示时区不同时，我们的脚本就可能表现出一些奇怪的行为（参见上一节的例子）。

以下函数和变量均采用与图表交易品种相同的时区进行工作：

由于这些函数和变量以交易品种的‘Exchange’（交易所）时区返回时间，因此通常最好也将图表的显示时区设置为‘Exchange’。这样我们就能避免脚本的计算基准与图表的视觉呈现之间产生差异。

例如，假设我们使用 time() 函数来判断一根价格K线是否落在特定的交易时段内。如果我们没有将图表的时区设置为‘Exchange’，那么脚本判定属于该时段的K线，将与我们在图表时间轴上看到的落在该时间范围内的K线不一致。

注意事项

由于几乎所有TradingView内置函数和变量都使用交易品种的时区，因此图表的时区设置只起到视觉效果的作用：在后台，我们的指标和策略始终使用‘Exchange’（交易所）时区——这不一定与我们在图表上看到的时间相同。

通过始终将图表的时区设置为‘Exchange’，我们可以避免因交易品种所用时区与图表显示时区之间的差异而导致的困惑，以及由此产生的对编程错误的误判。

使用UTC时区的函数和变量

目前，有两个内置变量不使用交易品种的时区，而是以UTC时区返回它们的值：

由于 time 和 timenow 使用的时区与其他处理时间的TradingView函数和变量不同，我们不能将它们直接进行比较。当然，我们可以使用 time 和 timenow 来查看当前时间与某一根K线时间的关系。