サマータイム・標準時差変更対応の世界時計｜重複・欠落時刻も判定

使い方

1. 基準地を日本語名付きの206 IANA zoneから選び、その場所の壁時計年月日・時分を入力します。
2. 初期値のstop-and-askで計算し、route-codeとUTC逆変換候補数を確認します。
3. 時計の後退によるfoldで2候補なら、DST終了か標準時差変更かを問わず予定のUTCまたは明示offsetを調べ、earlier-utcかlater-utcを選んで再計算します。
4. ok routeになった後だけ変換先表を利用し、解決UTCと基準地の適用UTC差も記録します。

計算式・考え方

基準地のGregorian local minute Lについて、選択IANA zoneの各segmentのeffective offset oからU=L-oを作り、Uがそのsegmentの半開UTC区間に入る候補だけを残します。0候補は時計前進のtransition内部gap（DST開始・標準時差変更を含む）と期間外を分離し、2候補の時計後退fold（DST終了・標準時差変更を含む）はpolicyで停止・早いUTC・遅いUTCを選びます。解決Uへtarget effective offsetを加え、基準地との差はtarget effective-source effectiveで求めます。

注意事項

• サマータイムや標準時差変更に対応するページでは基準地を固定206 IANA zoneから選びます。国名だけでは複数zoneを区別できず、略号も重複するため、表示名とIANA zoneを並記したclosed selectにしています。
• local→UTC逆変換は、基準zoneの全segmentについて、入力した壁時計分からeffective offsetを引き、そのUTC候補がsegmentの半開区間内かを検査します。候補は固定dataset内で最大2件です。
• DST開始や標準時差変更に伴う時計の前進で存在しない現地時刻を入力した場合はstopped-nonexistent-local-timeです。端末任せで進めたり、前後どちらかへ丸めたりせず、入力を直すまで結果表を0行にします。
• DST終了や標準時差変更に伴う時計の後退で同じ現地時刻が二度現れる場合、初期値stop-and-askではstopped-ambiguous-local-timeです。早いUTC候補と遅いUTC候補を示し、利用者がearlier-utcまたはlater-utcを選ぶまで暗黙解決しません。
• America/New_Yorkの2026年11月1日01:30は05:30ZのEDTと06:30ZのESTに対応します。予定の出所に明示offsetやUTCがなければ、どちらかを時計表示だけで断定できません。
• America/New_Yorkの2026年3月8日02:30はspring gap内で存在しません。01:59の次は03:00となるため、02:30を正常な候補0件と混同せず停止routeを表示します。
• Australia/Lord_Howeの2026年4月5日01:45には30分離れた2候補があり、10月4日02:00〜02:29は30分gapです。DSTを1時間固定で判定しない理由がこの例です。
• DSTではない標準時差変更も同じ仕組みで判定します。Asia/Almatyの2024年2月29日23:30は+06と+05の2候補がどちらもDST調整なしで、America/Caracasの2016年5月1日02:45は時計の前進により存在しません。
• 逆変換候補0件でも、すべてをDST開始とは扱いません。transition内部の時計前進区間だけをnonexistentとし、固定datasetの端より外側はstopped-out-of-periodへ分けます。
• foldをearlier-utcまたはlater-utcで解決した後は、基準地自身の標準・適用UTC差、略号、DST状態を選んだ候補から再計算します。候補を選ぶ前の停止状態ではこれらをダッシュ表示します。
• 基準地との時差は、変換先effective offsetから選択済み基準地effective offsetを引きます。差を24時間で丸めないため、Pacific/NiueからPacific/Kiritimatiは+25:00となり、日付差も保たれます。
• 基準地としてEurope/Dublinを冬に選ぶとstandard UTC+01:00に対してeffective UTC+00:00となり、負のDST（-60分）です。Africa/Casablancaにも同様の期間があり、単純な夏・冬二分法では扱いません。
• Asia/KathmanduのUTC+05:45やAustralia/EuclaのUTC+08:45などを含むため、source-relative-offsetの分部分は00だけとは限りません。15分、30分、45分の差を保持します。
• 入力年2015〜2030は壁時計表示の年に対する受付範囲です。しかしUTCへ引き戻した結果が固定期間外ならstopped-out-of-periodで止まり、最初や最後のoffsetを外側へ延長しません。
• 変換先のlocal日付はUTC端で2014年または2031年になることがあります。基準入力の年制限を結果行へ重ねず、同じUTC instantへ各zoneのoffsetを加えたGregorian日をそのまま表示します。
• 206 zone選択は国名の推測ではなくcanonical IANA identifierへ結び付けます。同じ国に複数zoneがある場合、実際の都市・地域に対応する候補を選び、略号の一致だけで代用しません。
• このツールはcalculator-firstで、基準zone、現地日時、fold policy、地域をページ先頭で指定します。逆像探索と表生成はclient-onlyで、OSのIntl、現在時刻、位置情報、外部APIを利用しません。
• 固定投影には25地域、311行、206 zones、2,433 transition segmentsがあります。全segmentでis_dstとeffective-standardの非零判定を照合し、異なる端末でも同じrouteと値を返します。
• 停止routeは失敗を0時刻へ置き換えたものではありません。0行とroute-code、候補数を一緒に読み、gapなら実在時刻へ修正し、foldなら予定の出所を確認して候補を選びます。
• 複数人の予定調整では、fold候補を選んだ根拠もメモしてください。招待元にUTC、offset、航空券記載時刻などの証拠がなければ、earlierとlaterのどちらかを推測で確定しない運用が安全です。
• IANA tzdbは政治的な規則変更に合わせて更新されます。本版は2026年7月17日に検証した2026cであり、将来日の業務運用は開催前に公式時刻と最新版で再確認します。
• 航空、鉄道、取引所、法令期限などの時刻を本結果だけで確定しないでください。対象組織の予約記録や公表scheduleを優先し、本ページはDSTや標準時差変更による重複・欠落を発見する検算として使います。
• 出典証跡（article-only）: IANA tzdata2026c.tar.gzのarchive SHA-256はe4a178a4477f3d0ea77cc31828ff72aa38feff8d61aa13e7e99e142e9d902be4、detached signatureのSHA-256は26cd02e034eed682aa911d224bca3247ff15914df317e3bb0b1a01dc557b46feです。署名はGnuPGでGOODSIG/VALIDSIG、主鍵fingerprint 7E3792A9D8ACF7D633BC1588ED97E90E62AA7E34を確認し、ローカルのidentity trustはTRUST_UNDEFINEDとして過大評価しません。
• ライセンス証跡（article-only）: 配布物LICENSEは、個別に明記された一部コードを除きtz code/dataをpublic domainとする内容です。LICENSE SHA-256は0613408568889f5739e5ae252b722a2659c02002839ad970a63dc5e9174b27cf、確認日は2026-07-17です。
• 更新証跡（article-only）: dataset更新時はarchive署名とhash、LICENSE、206 zone、全transitionの半開区間、New YorkとLord Howeのgap/fold、負のDST、2015/2030のUTC端を再検証してから版を切り替えます。
• 【結果直下の注意】IANA tzdb 2026cを2026年7月17日に固定した2015〜2030年の参照計算です。DST・標準時差変更による時計の後退や前進でも、stopped-ambiguous-local-time、stopped-nonexistent-local-time、stopped-out-of-periodでは表を生成しません。将来変更へ自動追随せず、重要な予定は対象組織の公式時刻で確認してください。

よくある質問