Pine Scriptの取引時間とタイムゾーン設計｜夏時間のずれを防ぐ

結論：取引時間帯には必ず「誰の時計か」を付ける

「09:30–16:00」とだけ書いた取引時間帯仕様は不完全です。少なくともタイムゾーン、曜日、バー開始と終了のどちらを判定するか、期間が日をまたぐか、対象時間足を添えます。Pineでタイムゾーンを省略したtime()／time_close()は、既定でsyminfo.timezoneに対応する取引所時間を使います。

スクリーンショットにはチャートタイムゾーン、設定記録には計算タイムゾーンを残します。

time・time_close・hour・syminfo.timezoneを用途で選ぶ

UNIXタイムスタンプは絶対時刻です。タイムゾーンは、その時刻を作る暦入力や表示値の解釈に使われます。

not na(time(timeframe.period, session, timezone))は、現在バーの開始時刻が指定セッション内にあるかを調べる定番です。バー確定もセッション内であることを要求するならtime_close()を別に確認します。1時間バーが15:30に開始し16:30に終了する場合、09:30–16:00のセッションでは開始だけ内側という状態があり得ます。

時刻・曜日・日またぎ・バー整列を一つずつ読む

時刻ベースのセッション文字列は、基本的にHHmm-HHmm:daysです。曜日は1＝Sundayから7＝Saturdayの数字集合で、たとえば平日だけなら23456です。時刻区間をカンマで複数指定することもできます。input.session()は入力値で時刻を選びやすくしますが、曜日は別入力値として結合する設計が明確です。

取引所が定義するセッションと、時刻ベースのセッション文字列は別の概念です。

セッション終端が時間足のバー境界と合わないと、Pineの時間関数はその指定時間足用に内部バーを作って判定することがあります。見た目のチャートバーとの不一致を避けるには、開始・終了時刻を対象時間足のバー境界へそろえるか、開始／終了両側の判定を可視化して確認します。

地域時間には固定UTCからの時差ではなくIANAを使う

UTC-4は通年でUTCより4時間遅い固定オフセットです。America/New_Yorkは地域の時間ルールを表し、夏時間中はUTC−4、標準時間中はUTC−5へ自動調整します。両者は一年の一部で一致しても、同じ意味ではありません。

IANAは過去・将来の地域ルール変更にも対応するため、地域の現地セッションには公式が推奨する形式です。

1. 01夏時間切替前週を選ぶ

   同じ曜日・時刻のバー判定を記録します。

2. 02切替週を選ぶ

   固定UTCとIANAの差が出るバーを色分けします。

3. 03切替後週を選ぶ

   セッションの開始／終了と最初のエントリーを再確認します。

4. 04別取引所銘柄へ切り替える

   syminfo.timezoneと明示タイムゾーンのどちらを意図したか確認します。

価格や戻り値の比較ではなく、一つの現地取引時間帯定義が季節の時計変更を越えて同じ分類を作るかを試験します。

同じ曜日、現地時刻、チャート時間足を通常週と切替週で一対にします。UNIXタイムスタンプ、取引所表示、IANA表示、固定UTC表示、time()／time_close()の結果を保存します。IANA版だけが現地時刻を維持し、固定オフセット版が1時間ずれる検証例を対照として残すことで、試験が夏時間誤差を実際に検出できると証明します。

セッション文字列とIANAタイムゾーンを入力値へ明示する

次の教育用ストラテジーは、時刻、曜日、タイムゾーンを別入力値にし、バー開始が取引時間帯内のときだけエントリーを許可します。取引時間帯終了を検出したら保有中の建玉を終了します。移動平均交差は動作確認用であり、取引時間帯や銘柄の推奨ではありません。

//@version=6
strategy("IANA session filter audit", overlay = true,
         initial_capital = 100000, margin_long = 100, margin_short = 100)

string hoursInput = input.session("0930-1600", "Session hours")
string daysInput = input.string("23456", "Session days",
     options = ["23456", "1234567"])
string timezoneInput = input.string("America/New_York", "Session time zone",
     options = ["America/New_York", "Europe/London", "Asia/Tokyo", "Etc/UTC"])
string sessionString = hoursInput + ":" + daysInput

bool opensInSession = not na(time(timeframe.period, sessionString, timezoneInput))
bool sessionEnded = not opensInSession and opensInSession[1]

float fast = ta.ema(close, 20)
float slow = ta.ema(close, 50)
bool longSignal = ta.crossover(fast, slow)

if opensInSession and longSignal and strategy.position_size == 0
    strategy.entry("Long", strategy.long)

if sessionEnded and strategy.position_size != 0
    strategy.close_all(comment = "Session end")

bgcolor(opensInSession ? color.new(color.teal, 88) : na)
plot(fast, "Fast", color.aqua)
plot(slow, "Slow", color.orange)

監査版では、str.format_time()でバー時刻を取引所、Etc/UTC、選択IANAの三つへ整形して表やlogへ出すと、表示と判定の混同を見つけやすくなります。公開版では重い描画を必要最小限にし、入力値と説明へタイムゾーンを明記します。

この例のsessionEndedは、最初のセッション外バーをスクリプトが評価した時点でtrueになります。そのバーの終了計算でstrategy.close_all()が成行注文を生成し、標準的な模擬約定では実際の約定は次に利用可能なティックです。したがって「16:00に退出」と書かず、セッション終端、セッション外バーの開始／終了、注文作成、約定の四時刻を別列へ保存します。process_orders_on_closeを使う比較も別版であり、実ブローカーのセッション終端約定を保証しません。

バー開始とバー確定の取引時間帯所属を別々に試算する

ミニ計算機は24時間の単純な時計上で、取引時間帯開始・終了、バー開始、バー長を受け取り、開始端点と終了端点が区間内かを別々に返します。二端点の所属だけから、どの境界を何回通過したかまでは判定しません。タイムゾーン変換や夏時間そのものは計算せず、変換後の同一現地時計にそろえた値を入れる前提です。日またぎ区間にも対応する概念モデルです。

• 開始バーの開始が取引時間帯開始と一致するか
• 終了直前バーの終了が取引時間帯終端を越えないか
• 夏時間切替前後で同じ現地時刻のバーを選べるか
• 日またぎのエントリーと決済が同じ暦上の曜日へ誤分類されないか
• 低流動性や休場で期待した境界バーが欠けていないか

セッション境界確認表を時刻付き出力へ添える

1. 01時計を固定

   セッション文字列、曜日、IANAタイムゾーン、チャート時間足を保存します。

2. 02境界を可視化

   セッションの開始／終了、開始時点／終了時点のセッション内判定を確認します。

3. 03夏時間三期間を試験

   切替前・切替週・切替後で最初と最後の対象バーを照合します。

4. 04取引一覧を出力

   エントリー／決済時刻とタイムゾーンメモをCSV／XLSXへ添えます。

5. 05条件付きで分析

   時刻粒度があるファイルだけを取引時間帯・曜日・時間帯分析へ使います。

境界判定はスクリーンショットだけで終えず、セッション境界確認表へ残します。通常日と夏時間切替週について、開始直前、開始一致、終了直前、終了一致のバーを選び、IANAタイムゾーン、セッション文字列、曜日、開始／終了時刻、time()／time_close()の結果を一行ずつ保存します。

確認表と取引CSVは同じバージョンIDで結び、チャートタイムゾーンは表示用、取引所タイムゾーンは既定の計算時計、明示指定したIANAタイムゾーンはストラテジーが選んだ時計として別列にします。四つの確認が期待どおりでない版はセッション別の成績比較へ進めません。

分類が正しくても退出約定がセッション内とは限りません。バーのセッション内外判定と注文処理の流れを別々に合格させます。

再現手順は通常週、日またぎ、夏時間切替週の三組です。各組で最後のセッション内バーと最初のセッション外バーを固定し、開始／終了時点の内外判定、sessionEnded、終了注文の生成、実際の約定を順に記録します。次に時間足だけを変え、境界バーが欠ける場合や終端へ整列しない場合でも説明が維持されるか確認します。分類だけ合うが約定が遅れる実行を削除せず、退出設計の失敗として保存します。