2026 年のカナダのタイムゾーンの変更

2026 年 11 月 1 日、カナダのいくつかの州と準州（マニトバ州、アルバータ州、ブリティッシュ コロンビア州、ノースウェスト準州の一部）は、1 時間戻すのではなく、恒久的な夏時間（DST）に移行するか、夏の UTC オフセットを維持します。

IANA タイムゾーン データベース（tzdata 2026e）では、これらの変更により、次のタイムゾーンとエイリアスが更新されます。

リージョン 通年の UTC オフセット（2026 年 11 月 1 日より） 影響を受ける IANA タイムゾーン
マニトバ UTC-5（UTC-6 に戻るのではなく） アメリカ - ウィニペグ（America/Winnipeg）、カナダ - 中部（Canada/Central）、アメリカ - レイニーリバー（America/Rainy_River）
アルバータ UTC-6（UTC-7 にフォールバックする代わりに） アメリカ - エドモントン（America/Edmonton）、カナダ - 山岳部（Canada/Mountain）
ブリティッシュ コロンビア UTC-7（UTC-8 にフォールバックする代わりに） アメリカ - バンクーバー（America/Vancouver）、カナダ - 太平洋（Canada/Pacific）
ノースウェスト準州 UTC-6（UTC-7 に戻るのではなく） アメリカ - イヌヴィック（America/Inuvik）

このドキュメントでは、これらのタイムゾーンの変更が Looker に与える影響と、2026 年 11 月 1 日以降に 1 時間の時間オフセットを回避する方法について説明します。

タイムゾーンの変更が Looker に与える影響

2026 年のカナダのタイムゾーン変更は、データベースまたは Looker がタイムゾーンを評価するかどうかによって、Looker の機能に異なる影響を与えます。

  • SQL クエリ、フィルタ、カスタム ディメンション: Looker が Explore、Look、ダッシュボードの SQL を生成するときに、Looker は構成された IANA タイムゾーン識別子をデータベースに渡します。BigQuery などのマネージド クラウド データベースは、tzdata 2026e の更新を自動的に受け取ります。独自のデータベースを管理している場合は、データベースのタイムゾーン テーブルに tzdata 2026e 以降のバージョンが含まれていることを確認します。
  • スケジュール配信の実行時間: Looker は、バンドルされたスケジューラ（Ruby）のタイムゾーン データを使用して、コンテンツ配信の cron スケジュールを評価します。パッチが適用されていない Looker インスタンスでは、影響を受けるカナダのタイムゾーンのスケジュール実行時間が 2026 年 11 月 1 日から 1 時間ずれます。パッチが適用された Looker ビルドと、スケジュール配信タイムゾーンの回避策の両方で、この問題が修正されます。
  • UI の表計算: Looker UI で Explore またはダッシュボードを表示すると、Looker は、バンドルされたブラウザ（JavaScript）のタイムゾーン データを使用して、ブラウザで now() を使用する表計算を評価します。パッチが適用されていないインスタンスでは、2026 年 11 月 1 日以降、これらの計算が 1 時間ずれます。パッチが適用された Looker ビルドでは、この問題が修正されています。
  • サーバーで評価される表計算: Looker がサーバーで now() を使用する表計算を評価する場合（CSV と XLSX のダウンロード、スケジュール設定された配信内のデータ、API クエリ、アラートなど）、Looker は JVM で実行されます。JVM のバンドルされた JDK タイムゾーン データベースは引き続き tzdb 2026b です。このパッチではバンドルされた JDK が更新されないため、影響を受けるカナダのタイムゾーンのサーバー評価の now() 計算は、パッチを適用した Looker ビルドでも、2026 年 11 月 1 日以降 1 時間ずれたままになります。

次の表に、パッチビルドで修正される Looker 機能と、代替タイムゾーンを構成することで回避できる Looker 機能の概要を示します。

機能 パッチ適用済みのビルドで修正済みか？ 代替タイムゾーンの回避策で修正されましたか？
スケジュール設定された配信の実行時間 はい（スケジューラの Ruby タイムゾーン データを更新します） はい（スケジュールの配信タイムゾーンを更新します。これは配信の送信タイミングにのみ影響します）
UI の表計算 now()（Explore とダッシュボード） はい（ブラウザの JavaScript タイムゾーン データを更新します） 非推奨（クエリレベルのタイムゾーンを変更する必要があり、SQL の結果で過去の冬のデータが 1 時間ずれる）
サーバーで評価された表計算 now()（CSV および XLSX のダウンロード、スケジュール設定された配信内のデータ、API、アラート） Looker（Google Cloud コア）インスタンスと Looker ホスト型インスタンスでは「いいえ」（JVM はバンドルされた JDK tzdb 2026b を使用） 非推奨（クエリレベルのタイムゾーンを変更する必要があり、SQL の結果で過去の冬のデータが 1 時間ずれる）

スケジュール設定された配信と UI 表計算で 1 時間のオフセットが発生しないようにするには、パッチが適用された Looker バージョンにアップグレードします。2026 年 11 月 1 日までにパッチを適用できない場合は、スケジュールに代替の配信タイムゾーンを構成します。

パッチが適用された Looker バージョンにアップグレードする

Looker は、Looker 26.0 を除くすべてのサポートされている Looker バージョンで、スケジューラ（Ruby）とブラウザ（JavaScript）のタイムゾーン データを tzdata 2026e に更新するパッチビルドを提供しています。パッチ適用済みのビルドは、Looker 25.18、26.0、26.6、26.12、26.16、26.18、26.20、26.22、およびそれ以降のリリースで利用できます。Looker（Google Cloud コア）インスタンスと Looker ホスト型インスタンスでは、パッチが適用されたビルドは JVM のバンドルされた JDK タイムゾーン データベース（tzdb 2026b）を更新しないため、サーバーで評価された now() 表計算は 1 時間ずれたままになります。

Looker は、2026 年 11 月 1 日より前に、このパッチをすべてのインスタンスに自動的にデプロイすることはありません。サポートされている Looker バージョンのパッチ適用済みビルドをリクエストまたはダウンロードできます。

  • Looker（Google Cloud コア）インスタンスと Looker ホスト型インスタンス: インスタンスのパッチビルドへのアップグレードをリクエストするには、Cloud カスタマーケアにお問い合わせください。
  • セルフホスト型インスタンス: サポートされている Looker バージョンのパッチ適用済み JAR ファイルを取得するには、Looker のダウンロード ページから更新されたリリースをダウンロードするか、Cloud カスタマーケアにお問い合わせください。
    • サーバー評価の表計算: サーバー評価の表計算では、バンドルされた JDK ではなく、Java ランタイムのタイムゾーン データが使用されます。Oracle の tzupdater ツールなどを使用して、Java ランタイムのタイムゾーン データを更新します。これにより、America/Winnipeg などの影響を受けるカナダのタイムゾーンが正しく評価されます。
    • システム アクティビティのタイムスタンプ: サーバーのシステム タイムゾーンが、影響を受けるカナダのタイムゾーン（America/Winnipeg など）に設定されている場合、2026 年 11 月 1 日以降、システム アクティビティのタイムスタンプも 1 時間ずれます。

別のタイムゾーンを設定する

2026 年 11 月 1 日までにパッチが適用されたビルドにアップグレードしない場合、またはインスタンスで Looker 26.0 が実行されている場合は、リージョンの UTC オフセットに一致する代替タイムゾーンを構成できます。

  • マニトバ（America/Winnipeg、Canada/Central、America/Rainy_River - UTC-5）: 夏時間を採用せず、年間を通じて UTC-5 のままのタイムゾーンを選択します。たとえば、アメリカ - アティコカン（America/Atikokan）、アメリカ - カンクン（America/Cancun）、アメリカ - パナマ（America/Panama）、アメリカ - ボゴタ（America/Bogota）、アメリカ - リマ（America/Lima）、アメリカ - ジャマイカ（America/Jamaica）などです。
  • アルバータ州（America/Edmonton、Canada/Mountain）とノースウェスト準州（America/Inuvik - UTC-6）: 夏時間を採用せず、年間を通じて UTC-6 のままのタイムゾーンを選択します。たとえば、アメリカ - レジーナ（America/Regina）、カナダ - サスカチュワン（Canada/Saskatchewan）、アメリカ - グアテマラ（America/Guatemala）、アメリカ - コスタリカ（America/Costa_Rica）、アメリカ - ベリーズ（America/Belize）などです。
  • ブリティッシュ コロンビア（America/Vancouver、Canada/Pacific - UTC-7）: 夏時間を採用せず、年間を通じて UTC-7 のままのタイムゾーンを選択します。たとえば、アメリカ - フェニックス（America/Phoenix）、アメリカ - ドーソン クリーク（America/Dawson_Creek）、アメリカ - フォート ネルソン（America/Fort_Nelson）、アメリカ - クレストン（America/Creston）、アメリカ - ホワイトホース（America/Whitehorse）、アメリカ - ドーソン（America/Dawson）などです。

Looker でタイムゾーンの設定を更新する

スケジュールされた配信が 1 時間ずれて実行されないようにするには、影響を受けるスケジュールの配信タイムゾーンを別のタイムゾーンに更新します。スケジュールの配信タイムゾーンを変更しても、クエリが返す時間ベースのデータではなく、配信が送信される配信時間のみが制御されるため、安全です（タイムゾーンの設定を使用するをご覧ください）。

  • アプリケーションのタイムゾーン: [管理] パネルの [全般設定] ページで [アプリケーションのタイムゾーン] の設定を更新して、新しいスケジュールのデフォルトのタイムゾーンを設定します。既存の各スケジュールには独自のタイムゾーンが保存されるため、既存のスケジュールを個別に更新する必要があります。
  • スケジュール設定されたコンテンツ配信: 影響を受ける各ダッシュボード、Look、Explore のスケジュールを開き、配信タイムゾーンの設定を更新します。手順については、ダッシュボードのスケジュール設定と送信と Look と Explore の配信をご覧ください。

それでも、表計算で now() を回避するためにクエリレベルのタイムゾーン設定を更新し、過去の冬の SQL 結果の 1 時間のシフトを受け入れる場合は、影響を受けるカナダのタイムゾーンが構成されている次の設定を変更できます。

  • ユーザー アカウントのタイムゾーン: [ユーザー固有のタイムゾーン] が有効になっている場合は、[管理] パネルの [ユーザー] ページでユーザーのタイムゾーンを更新します。個々のユーザーは、[アカウント] ページで [タイムゾーン] の設定を更新することもできます。
  • データベース接続クエリのタイムゾーン: ユーザー固有のタイムゾーンが無効になっている場合は、[管理] パネルの [接続] ページで [クエリのタイムゾーン] の設定を更新します。