海外締切を日本時間に直すとき、足し算だけでは危ない。日付・DST・曖昧時刻まで14ケースで確かめた

海外サービスの申込、論文投稿、イベント登録、入札。締切に「July 15, 5:00 PM」と書かれていると、日本時間へ変換してカレンダーに入れたくなります。UTCとの時差を調べて、何時間か足す。普通の日時なら、これで合うことも多いです。

ただ、締切管理で怖いのは「大半は合う」ことです。一度間違えば受付終了になる業務では、タイムゾーン変換は時差の暗算ではなく、原文が指す一つの時点を確定する作業として扱った方が安全です。

今回はIANAのタイムゾーンとPython標準の`zoneinfo`を使い、まずT01〜T08・T10・T11の10ケースを基準比較しました。そのうちT01〜T06・T10・T11の8ケースで日本側の日付が変わりました。さらにT09・T12・T13・T14を追加し、地域差やDST周辺を含む14ケースで境界を確認しました。

同じロサンゼルス17時でも、冬と夏で答えが違う

まず分かりやすいケースです。2026年1月15日17時、`America/Los_Angeles`。この時期はUTC-8なので、日本時間では翌16日10時です。一方、2026年7月15日17時はUTC-7になり、日本時間は翌16日9時です。

同じ街、同じ17時。それでも季節によってJSTが1時間違います。「ロサンゼルスは日本より17時間遅い」と固定値で覚えると、別の季節に壊れます。IANA Time Zone Databaseは、地域ごとのUTC offsetだけでなく、daylight saving timeなどのルールを保持し、政治的な変更に応じて更新されます。

つまり地域名を使う意味は、単に「現在の時差を引く」ことではなく、その日付に適用されるルールを選ぶことにあります。

基準10ケース＋追加4ケースを変換した

今回の制御ケースです。

ID：T01
地域：Los Angeles
現地時刻：1/15 17:00
JST：1/16 10:00

ID：T02
地域：Los Angeles
現地時刻：7/15 17:00
JST：1日後 09:00

ID：T03
地域：New York
現地時刻：3/10 23:30
JST：翌日 12:30

ID：T04
地域：London
現地時刻：1/20 23:00
JST：翌日 08:00

ID：T05
地域：London
現地時刻：7/20 23:00
JST：翌日 07:00

ID：T06
地域：Berlin
現地時刻：10/20 23:30
JST：翌日 06:30

ID：T07
地域：Sydney
現地時刻：1/15 23:30
JST：同日 21:30

ID：T08
地域：Sydney
現地時刻：7/15 23:30
JST：同日 22:30

ID：T09
地域：Auckland
現地時刻：3/15 23:00
JST：同日 19:00

ID：T10
地域：Singapore
現地時刻：8/18 23:30
JST：8/19 00:30

ID：T11
地域：Kolkata
現地時刻：8/18 23:30
JST：8/19 03:00

ID：T12
地域：Chicago
現地時刻：11/2 23:30
JST：11/3 14:30

ID：T13
地域：Paris
現地時刻：3/28 23:30
JST：3/29 07:30

ID：T14
地域：Honolulu
現地時刻：8/18 23:30
JST：8/19 18:30

注目したいのは、変換後の「時刻」だけではありません。日付が変わるかどうかです。海外締切を日本で管理するとき、時刻の数字より日付跨ぎの方が実務上の事故になりやすいことがあります。

「7月15日締切」とだけメモしておき、実際のJSTが7月16日朝なら、まだ間に合うと思っていたり、逆に一日早く締め切ったりします。だから変換結果は、

• 原文の締切

• JST換算

• 日付変化あり／なし

を分けて残す方が扱いやすいです。

`UTC-5`と`America/New_York`は同じではない

ここはよく混ざります。`UTC-5`は固定offsetです。一方、`America/New_York`は地域のtime zoneです。ニューヨークでは季節によってDSTが適用され、UTCとのoffsetが変わります。

したがって、「ニューヨーク＝UTC-5」と年間固定で処理すると、夏季にずれます。RFC 7808でも、time zone dataはUTC offsetだけではなくDSTルールを含むものとして説明されています。

固定offsetはある時点の関係を表すには便利です。しかし、「毎年7月15日17時ニューヨーク時間」のような地域のローカル時刻を将来まで扱うなら、地域zoneを使う理由があります。

もっと危ないのは、存在しない時刻と二つ存在する時刻

DSTの切替日には、普通の日にはない問題が起きます。時計を1時間進める地域では、ローカル時刻の一部が飛びます。たとえば1:59の次が3:00になるなら、その日の「2:30」は存在しません。

反対にDST終了時には、時計を戻すので同じ時刻帯が二度現れることがあります。「1:30」が二つある、という状態です。RFC 9557では、ローカル時刻からtimestampへ変換するとき、time zoneの切替付近では候補がゼロ個または複数個になり得ることが説明されています。

ここまで来ると、単純な「時差を足す」は使えません。締切原文がこの曖昧帯に入っていたら、主催者がどちらを指しているか確認する必要があります。Pythonの`zoneinfo`にも、この曖昧性を扱うための`fold`があります。

重要なのはプログラムの機能名ではなく、ローカル時計の文字列だけでは、一つの瞬間に決まらない場合があると知っておくことです。

`CST`や`IST`だけなら、変換しない方がいい場合がある

略称も危険です。`CST`と書かれていたとき、それがどの地域を指すか文脈が必要です。`IST`も同様です。締切文面に都市やIANA zone相当がなく、略称だけが書かれているなら、AIは文脈から推測できます。

しかし推測できることと、確定してよいことは別です。締切業務では、「たぶんこのCSTです」を自動変換するより、zone不明のためHOLDとする方が安全な場合があります。

AIの役割は、分からないものを全部埋めることではありません。「この入力では一意に決まりません」と止めることも、かなり重要な支援です。

AoEは都市名ではない

論文や国際イベントでは`Anywhere on Earth`、AoEという表現を見ることがあります。これは「あなたの所在地の23:59」という意味ではありません。運用上、日付を世界で最後まで残すためにUTC-12を基準とする形で使われます。

ただし、これも主催者の定義を原文で確認すべきです。「AoEだからいつでもUTC-12」と記憶だけで処理するのではなく、主催者ページに明示された締切定義を保存する。締切ではこの原文保存が強いです。

公式締切と社内締切を混ぜない

実務では、公式締切より早い社内締切を設けることがあります。たとえば公式が8月20日23:59 New Yorkで、JSTでは8月21日昼前。社内では確認時間を取るため、8月20日18時JSTを提出締切にする。

これは良い運用です。ただしデータ上、公式締切：8/21 12:59 JST
内部締切：8/20 18:00 JSTを分けて残した方がいい。内部締切だけ残すと、後から「公式にはまだ間に合ったのか」が分かりません。

逆に公式締切だけ残すと、チーム内の安全余裕が消えます。AIにリマインダーを作らせる場合も、この二つを別フィールドにすると判断が安定します。

変換結果を再利用するなら、offsetだけ保存しない

今日、ある日時を変換して、「この地域はUTC-7だった」と結果だけ保存する。半年後、別の日付へ同じ-7を使う。これが典型的な再利用事故です。保存したいのは、

• 原文

• IANA zone name

• 現地日時

• 変換時点のtzdb

• JST結果

です。IANAのdatabaseは政治的決定に合わせて更新されます。将来のルールが変われば、過去に計算した「将来締切」の結果を見直す必要もあります。特に数カ月先・翌年のイベントは、登録時点で一度変換して終わりではなく、期限が近づいたら主催者原文とtime zone dataを再確認する方が安全です。

14ケースを地域ごとに読むと、「時差表」では見えないものがある

北米：同じ都市でも季節で1時間変わる

Los Angelesは冬のT01と夏のT02で、同じ17時でもJSTが10時と9時へ分かれました。LondonもT04/T05で8時と7時。SydneyもT07/T08で21時30分と22時30分。

この三組だけで、固定時差表の弱点が分かります。必要なのは「都市の標準時差」ではなく、対象日付にその地域が採用しているoffsetです。

アジア：DSTがなくても日付跨ぎは残る

Singapore 23:30はJSTで翌0:30。Kolkata 23:30は翌3:00。DSTがないから簡単、とは限りません。業務上重要な「締切日が日本で何日になるか」は、純粋なoffsetだけで普通に変わります。

オセアニア：日本より先に進む地域では「翌日」にならない

SydneyやAucklandは、日本と比べて進んでいる時間帯があります。現地23時台をJSTへ戻すと、同日の夜になります。海外締切を全部「日本では翌日になる」と覚えるのも危険です。

方向が逆の地域があります。

DST開始日の「存在しない2:30」をどう扱うか

具体的に考えます。ある地域で時計が2:00から3:00へ進む日、原文に「2:30 deadline」と書かれていた。そのローカル時刻は存在しません。プログラムによっては、入力を受け付けて何らかのoffsetを割り当ててしまうことがあります。

しかし締切という意味では、主催者の表記ミスか、標準時を意図したか、別のtimezoneを意図したかを確認すべきです。計算できることと、意味が確定していることを分ける。

この境界はAIにも必要です。

DST終了日の「二つの1:30」

反対に、時計を1時間戻す日は1:30が二回現れます。一回目の1:30と二回目の1:30は、UTCでは別の瞬間です。RFC 9557が扱う「local timeからtimestampへ戻すと複数候補があり得る」という問題です。

もし締切がこの時刻に設定されていたら、`1:30 America/New_York`だけでは一つに決まりません。主催システムのtimestamp、offset付き表記、説明文など追加Evidenceが必要です。

ここでAIが「一般には標準時側でしょう」と推測して一つに決めるのは、便利ですが危険です。

略称の危険は、変換精度より「意味の確定」にある

`CST 5:00 PM`。AIは検索や文脈から候補を出せます。しかし、どのCSTかが原文で確定していなければ、変換結果に小数点以下まで正確な時刻を出しても意味がありません。

入力の意味が曖昧なのに、出力だけ精密になる。これはAIでよく起きる「精密そうな不確実性」です。だから締切換算では、timezone confidenceのような概念を持つと使いやすいです。

• Exact：IANA zoneやoffset付きtimestampが明記

• Strong：都市・国と日付から地域zoneが明確

• Ambiguous：略称だけ

• Missing：zone記載なし

Ambiguous/Missingは自動確定しない。このルールなら、AIが賢くなっても安全側を維持できます。

変換時刻だけ保存すると、再監査できない

たとえばカレンダーに「8/21 12:59」とだけ登録した。半年後、「なぜこの時刻だった？」と聞かれても分かりません。元の締切文、zone、変換ロジックが残っていないからです。

最低限、

項目：source text
例：Aug 20, 11:59 PM America/New_York

項目：source URL
例：主催者ページ

項目：zone
例：America/New_York

項目：source local
例：2026-08-20 23:59

項目：JST
例：2026-08-21 12:59

項目：converted at
例：2026-08-16

項目：internal cutoff
例：2026-08-20 18:00 JST

のように残します。こうすると、tzdbや主催者情報が変わった時に再計算できます。

締切まで半年ある場合と、明日の場合では運用を変える

将来のtimezone ruleは政治的に変わることがあります。IANA databaseはそうした変更を取り込みます。そのため半年後の締切を今日変換した場合、予定登録用の暫定換算

として保存し、期限が近づいたら再確認する運用が合理的です。一方、明日の締切なら現在のtzdbと原文でほぼ確定できます。すべての締切を同じ頻度で再確認する必要はありません。

「将来距離」がUpdate Triggerになります。

AIへ渡すプロンプトより、入力schemaの方が効くことがある

「絶対に間違えず日本時間へ変換してください」と強く書くより、

• deadline_text

• date

• local_time

• timezone_name

• source_url

• confidence

を分けて渡す方が安定することがあります。timezone_nameが空ならHOLD。略称だけならAmbiguous。IANA nameなら計算。このように、分からない入力を分からないまま残せるschemaを作る。

締切自動化ではこれが強いです。

AIへ任せるなら六段階に分ける

今回の14ケースと仕様をまとめると、次の流れが扱いやすいです。

1. 原文を保存する

日時だけ抜き出す前に、締切文そのものとURLを残します。

2. zoneを確定する

`America/New_York`のように地域が確定しているかを見る。略称だけならHOLD候補です。

3. その日付の規則で変換する

現在の時差ではなく、対象日付のIANA ruleを使います。

4. 日付跨ぎを明示する

JSTへ変換した結果、翌日・前日になったかを別に表示します。

5. 曖昧帯を止める

DST fold/gapに入る場合、人間確認へ回します。

6. 内部締切を別に作る

公式締切を上書きせず、社内余裕を別列で管理します。この順序ならAIはかなり役立ちます。文章から日時・地域を抽出し、IANA zoneへ正規化し、JSTを計算し、日付跨ぎや曖昧性を警告する。

ただしzoneが確定しない場合に、もっともらしい答えを強制しないことが重要です。

変換事故を八つのFailureへ分解する

Failure 1：現在の時差を未来へ流用

今日のNew Yorkのoffsetを半年後へ使う。DSTや制度変更で壊れます。

Failure 2：固定offsetを地域zoneとして扱う

UTC-5とAmerica/New_Yorkを同義にする。季節でずれます。

Failure 3：日付だけ保存

JSTで翌日になったことを失う。チーム内の「20日締切」という言葉が曖昧になります。

Failure 4：略称を推測確定

CST/IST等を文脈から一つへ決める。入力Evidenceが足りないのに出力だけ確定します。

Failure 5：DST gapを通常時刻として計算

存在しないローカル時刻を機械的にtimestamp化する。主催者意図の確認が必要です。

Failure 6：DST foldの二候補を一つへ潰す

同じ1:30のどちらかを根拠なく選ぶ。offset付き原文や主催システムのtimestampへ戻ります。

Failure 7：公式締切を社内締切で上書き

安全余裕は作れても、後から公式期限が分からなくなります。

Failure 8：一度変換した結果を永久利用

tzdbや主催者更新を反映できません。将来締切にはrecheck triggerが必要です。

期限までの距離で再確認頻度を変える

すべてを毎日確認する必要はありません。たとえば、

• 90日超：登録時に原文とzone保存。月次程度で更新確認。

• 30〜90日：主催者変更通知を確認。

• 7〜30日：tzdb/原文を再確認し、JSTを再計算。

• 7日以内：公式ページと受付画面を最終確認。

• 24時間以内：内部締切を優先し、原文更新がないか確認。

これは一例です。重要なのは、将来の不確実性が時間とともに減るように再確認することです。

カレンダー登録時にタイトルだけへ埋め込まない

`締切 8/21 12:59`だけを予定名にすると、変換根拠が消えます。説明欄やmetadataに、

• Original: Aug 20 23:59 America/New_York

• JST: Aug 21 12:59

• Source URL

• Checked: Aug 16

• Internal cutoff: Aug 20 18:00 JST

を残します。これなら担当者が変わっても再確認できます。AIがリマインダーを生成する場合も、sourceとchecked_atを残すことで「古い変換」を検出できます。

「変換できた」ではなく「締切を確定できた」を完了条件にする

日時ライブラリがエラーを出さず値を返した。それだけでは完了にしません。

• source date/timeが読めた

• timezoneが一意

• fold/gapではない、または解消済み

• JSTへ変換

• 日付跨ぎ確認

• source URL保存

• internal cutoff分離

ここまで揃って初めて「確定」です。この完了定義なら、AIの成功率を「計算できた件数」ではなく「根拠付きで確定できた件数」で測れます。

結論

海外締切の換算で本当に必要なのは、「何時間足すか」を覚えることではありません。その文字列が指す一つの瞬間を、根拠付きで確定することです。

同じ都市でも季節でoffsetが変わる。
固定offsetと地域zoneは違う。
日付が変わる。
存在しないローカル時刻がある。
二度存在するローカル時刻もある。
略称だけでは場所が決まらない場合がある。
そしてルール自体も更新される。

だから、AIに締切換算を任せるなら、原文 → zone確定 → 対象日のルール → JST → 日付跨ぎ → HOLD条件までを一つの処理として持つ。そうするとAIは「時差計算機」より一段上の、締切を取り違えないための確認装置として使いやすくなります。

確認に使った主な資料

• IANA Time Zone Database
  https://www.iana.org/time-zones

• RFC 7808
  https://www.iana.org/go/rfc7808

• RFC 9557
  https://www.iana.org/go/rfc9557

• Python zoneinfo
  https://docs.python.org/3/library/zoneinfo.html

思考削減AI｜実践ライブラリ

AIを使って「考える・調べる・やり直す」を減らすための実践ライブラリです。思考削減AIでは、AIの答えをそのまま信じるのではなく、実際に試し、比べ、検証しながら、仕事で使える方法を探しています。ベーシックプランでは、対象の有料記事をまとめて読むことができ、今後の対象記事や、材料が十分にあるときのメンバー限定記事も追加します。

「1記事だけではなく、いろいろ試しながら使いたい」という方は、こちらから確認できます。

https://note.com/mudakezuri/membership