米国の夏時間が11月1日に終了 ずれるジョブと会議の見分け方

日本時間で動くジョブとUTCで動くジョブは、米国の夏時間が終わっても、日本の時計の上では1分も動きません。

動くのは米国の現地時刻を基準にしたものだけ。2026年11月1日（日）を境に日本時間で1時間遅くなり、Windowsの月例更新なら、公開の目安は午前2時から午前3時に変わります。

ただ、「UTCで書いてあるから関係ない」とは言い切れません。米国の営業時間に合わせたつもりのジョブは、エラーも出さずに、米国の時計では1時間早く動き始めるからです。

切り替わりは、日本の日曜の午後

NISTによると、2026年の米国の夏時間は11月1日の現地時刻の午前2時に終わります。午前2時に時計が午前1時へ戻り、その1時間をくり返す仕組みです。つまり、2回来るのは2時ではなく1時台。

現地の午前2時は地域ごとに違うので、日本時間の切り替わりは、本土の4地域では15時から18時まで広がります。

NISTは、ハワイとアリゾナ州（ナバホ族の居留地を除く）は夏時間を採用していないと説明しています。そこにある拠点との時差は変わりません。

欧州は一足先に終わりました。英国政府の案内では2026年の切り替えは10月25日で、EUも10月の最終日曜と定めているので同じ日です。ロンドンとの時差は8時間から9時間へ、パリなど中央ヨーロッパとは7時間から8時間に変わりました。

そのため今週だけ、ニューヨークとロンドンの差はいつもの5時間ではなく4時間でした。日米欧をつなぐ会議の調整が今週だけ合わなかったなら、これが理由かもしれません。

基準は3つ、答えはそれぞれ違う

「ずれますか」と聞かれたら、まず「何の時計で動いていますか」と聞き返すことになります。

下の2行は答えが同じです。日本側の作業時間に影響はなく、問題が出るとすれば米国側との関係だけ。

10月と11月の日本時間を具体的に並べると、次のようになります。会議とcronの時刻は説明のための例です。

定例会議がどの行に当たるかは、作られたときのタイムゾーンによります。Googleカレンダーのヘルプによると、予定は招待された人それぞれのタイムゾーンで表示され、予定ごとにタイムゾーンを選べます。米国のタイムゾーンで作られた定例なら、日本の画面では来週から1時間遅く見えるはずです。東海岸との朝の会議は23時開始になり、自宅から入る人にはつらい1時間でしょう。

UTCのcronは、ずれないから見落とす

いちばん見落としやすいのは、実はUTCで書いたジョブかもしれません。エラーが出ないからです。

たとえば、米国西部の17時の締めを待って日本の朝に集計するジョブを、UTC 00:30で書いたとします。10月は太平洋時間の17:30に動くので、締めの30分後。11月からは16:30に動き、締めの30分前になります。ジョブは成功し、最後の30分が足りない数字が朝の報告に載るわけです。

GitHub Actionsの文書には、scheduleは既定でUTCで動き、timezoneにIANAのタイムゾーン名を書けるとあります。Cloud SchedulerとAzure Functionsのタイマーも既定はUTCです。Googleは文書の中で、実行の間隔を厳密に保ちたいならUTCを勧めています。二重実行を避ける意味では正しい助言ですが、米国の営業時間に合わせる用途では別の確認が要ります。

計算は簡単です。UTCから太平洋時間へは7時間引いていたものを8時間に、東部時間へは4時間引いていたものを5時間にします。米国の始業前に終わっていればよいジョブは1時間早くなるだけなので、そのままで構いません。

AWSのEventBridge Schedulerには、もう一つ見落としやすい点があります。rate(1 days)は日付ではなく前回の実行から24時間後を指すので、毎日動かすものは、切り替えを境に現地の時計で1時間早くなるはずです。

月例更新は水曜の午前3時になる

Microsoftの文書によると、月例のセキュリティ更新は毎月第2火曜に、通常は太平洋時間の午前10時に公開されます。

The monthly security update is published on the second Tuesday of each month, typically at 10:00 AM Pacific Time (PST/PDT).

「typically」とある以上、この時刻は保証ではなく目安です。2026年11月の第2火曜は10日なので、日本では11月11日（水）の午前3時が目安になります。

朝9時から情報を見始める運用なら、手順は何も変わりません。公開から9時までの余裕が7時間から6時間に縮むだけです。

困るのは日本時間の2時台に固定した自動処理です。たとえば2時半に更新カタログを同期する設定は、10月は公開の30分後に走っていましたが、11月は30分前に走るので、その回には載りません。夜間に当番を置いている会社も、開始を1時間後ろへずらすことになります。

SaaSの予告も同じ目で読みます。Zoomの稼働状況ページは、同じお知らせの中で投稿時刻をPDT、予定をPSTと書いています。11月7日の最小バージョンの変更は「Nov 7, 16:00 - 17:00 PST」で、日本時間では11月8日の9:00からです。10月の感覚で16時間を足すと8:00になり、1時間早く身構えることになります。

一方、Amazon RDSは既定のメンテナンスウィンドウを選ぶ時間帯をUTCで示していて、東京リージョンは13:00〜21:00です。日本時間の22:00から翌6:00にあたり、11月になっても動きません。メンテナンスの予告は、数字より先に、どの時計で書かれているかを確かめたいところです。

日次の上限も見落としがちでしょう。Google Cloudの日次クォータは太平洋時間の午前0時にリセットされるので、回復は日本時間の16時から17時に変わります。

1時台が2回来る時間帯、ジョブは何回動くか

該当するジョブは、米国のタイムゾーンを指定し、現地の1時台に時刻を置いたジョブです。動かすなら、日本時間の11月1日14時（東部）から17時（太平洋）の前までです。

7つの仕組みの文書を読み比べると、書きぶりはかなり違いました。

一般の決まりとして「runs only once and does not repeat its invocation」と書いたクラウドはAWSだけです。ただ、同じ文書の例は2:59から2:00へ戻るとしていて、NISTの1時台と合いません。Googleは「execution anomalies」が起きうると書くにとどめ、GitHubの注記は春の話で終わっています。

Kubernetesの行は、本家の文書を読めなかったので、Red HatのOpenShiftのAPI文書によるものです。GKEの文書はCronJobの時刻をUTCと説明しているので、環境ごとに基準を見る必要があります。

意外だったのは、同じプロジェクトのmanページなのに説明が逆だったcronieです。

Conversely, if time was adjusted backward, running the same job twice is avoided.

Similarly, times that occur more than once (again, during the daylight savings time conversion) will cause matching jobs to be run twice.

cron.8は、1時間より短い間隔のジョブはこの特別扱いの対象外とも書いています。比較はすべて文書の記述で、実機では検証していません。cronの実装は1つではないので、自社のサーバーに入っているものの文書を読むのが近道です。

編集部は、実害が出る会社は多くないとみています。図の3つの問いがすべて「はい」になるのは、米国拠点のサーバーの夜間バッチくらいだからです。もっとも、請求や外部への送信が二重に走れば、後始末は1時間では済みません。文書が書いていない動作に賭けるより、その1回だけ時刻を移すほうが安く済みます。

同じ時刻が2回あるログ

ログの突き合わせは、11月1日をまたぐ調査で迷いがちです。CloudTrailのeventTimeはUTCで、Microsoft Purviewの監査ログ検索も日時をUTCで示します。こちらは連続しているので心配いりません。

厄介なのが、現地時刻でオフセットを持たないログ。太平洋時間の「01:30:00」は11月1日に2回あり、1回目は日本時間17:30、2回目は18:30です。行だけでは区別できません。

米国拠点のサーバーやSaaSから書き出したCSVを扱うなら、突き合わせの表にUTCの列を作るのが確実です。太平洋時間に「+16時間」で固定した換算列がExcelにあれば、切り替わりのあとの行は「+17時間」に変わります。インシデントの時系列でも、-07:00と-08:00を書き分けておくと、あとで読む人が迷いません。

影響を受ける会社、受けない会社

次のどれかに当てはまる会社は、影響を受けます。

• 米国の拠点や親会社、取引先、委託先と定例会議がある
• 米国の営業時間や締めに合わせたジョブがある（UTCで書いたものも含む）
• 太平洋時間で予告されるSaaSのメンテナンスや期限を、日本時間に直して運用に載せている
• 月例更新の公開に合わせて、夜間の自動処理や当番を動かしている

当てはまらなければ、作業はありません。日本に夏時間はないので、国内で閉じたサーバーの時計やタイムゾーンの設定を変える必要もありません。欧州との付き合いだけなら切り替えは先週済んでいますし、アリゾナやハワイの拠点との時差はそのままです。

今日15分で終わる確認の手順

順番は、見つけやすいものからです。かっこの中の時間は目安です。

1. 来週の米国側との定例を開き、今週の同じ会議と日本時間の開始を比べます（3分）。1時間遅くなっていれば米国基準なので社内に知らせ、同じ時刻なら日本かUTCの基準なので米国側の開始が1時間早くなると相手に伝えます。
2. 下のコマンドと、EventBridge SchedulerやCloud Schedulerの管理画面でジョブを洗い出し、「基準のタイムゾーン」と「米国の何に合わせたか」の2列で一覧にします（5分）。米国拠点のサーバーはtimedatectlでタイムゾーンを見て、crontab -lと/etc/cron.dの時刻を確認します。
3. 米国のタイムゾーンで1時台に動くジョブに印を付けます（2分）。二重に動くと困る処理なら、11月1日の回だけ時刻を移し、11月2日に元の時刻へ戻します。
4. UTCと日本時間のジョブから、米国の営業時間や締めに合わせたものを選び、太平洋は8時間、東部は5時間の差で計算し直します（3分）。ずれて困るものは実行時刻を1時間遅らせるか、3月にまた直さずに済むようタイムゾーンの指定に変えます。
5. 運用メモを直します（2分）。月例の当番の開始、11月11日3:00という目安、「+16時間」の換算式を改め、日曜の当番には1時台に動くジョブの名前と移した時刻、11月2日に戻す作業を伝えます。

grep -rniE --exclude-dir=.git --exclude-dir=node_modules '\bUS/|cron|schedule|rate\(|America/|TZ=|time.?zone' <リポジトリのパス>

cronとscheduleで広めに拾うので、既定のUTCのジョブも一覧に入ります。

次に時計が動くのは、NISTの決まりどおりなら2027年3月14日です。今度は時差が1時間縮み、2時台が飛びます。手順2の一覧を残しておけば、春はそれを見直すだけで済むはずです。