結果はどうやって計算されるの?
ワルシャワ、ニューヨーク、東京の1日
ワルシャワは9:00〜17:00(UTC+2)、ニューヨークは9:00〜17:00(UTC−4)、東京は9:00〜18:00(UTC+9)で勤務するとします。ワルシャワの時間帯はUTC 7:00〜15:00、ニューヨークはUTC 13:00〜21:00、東京はUTC 0:00〜9:00です。共通するのはUTC 13:00〜15:00の2時間だけです。ワルシャワでは15:00〜17:00、ニューヨークでは9:00〜11:00、東京では22:00〜24:00になります。これが予約すべき時間帯です。
入力と出力の例 | 入力 | 値 |
| date | 2026-08-04 |
| windows | Warsaw 09–17, New York 09–17, Tokyo 09–18 |
| 結果 | 13:00–15:00 UTC(2時間)・ワルシャワ 15:00–17:00・ニューヨーク 09:00–11:00・東京 22:00–24:00 |
計算式と前提は?
UTCでの勤務時間帯
window(zone) = [startHour, endHour) local, converted per minute
計算式の記号 | 記号 | 意味 |
[start, end) | 開始時刻を含み、終了時刻を含みません |
converted per minute | 1分ごとに現地時刻で評価されます |
1分ごとの評価により、日中のサマータイム移行も正確に処理されます。固定オフセットの前提はありません。
重なり
overlap = ⋂ window(zone) for all zones
計算式の記号 | 記号 | 意味 |
⋂ | 共通部分: すべての時間帯に含まれる分 |
よくある間違いは?
- ゾーンのオフセットは固定だと思い込むこと。1時間のサマータイムのずれは、固定オフセットで計画した会議を静かに壊します。
- 開始時刻の重なりだけで計画し、あるゾーンの終了時刻で時間帯が短くなることを無視すること。
- 「9:00〜17:00」は各ゾーンの現地時刻であり、共通の時間ではないことを忘れること。
前提と制限は?
- 一度の実行で計画できるのは1日分です。定期的なパターンは日ごとに確認する必要があります。
- バージョン1の時間帯は設計上、1時間単位です。30分単位の勤務時間には対応していません。
- このプランナーが探すのは勤務時間内の時間帯であり、個人のカレンダーを確認するものではありません。
数値の出典は?
最終確認 2026年8月4日 · バージョン 1.0.0 · Toolivaro 外部コンテンツを保証するものではありません。
よくある質問
サマータイムの移行はどう処理されますか?
その日の1分1分を各ゾーンの現地時刻で変換するため、日中の途中でオフセットが変わるゾーンでも、時間帯が実際にずれて反映されます。プランナーが固定オフセットを前提にすることはありません。これは春と秋の移行の前後の週に最も重要です。
重なりがない場合はどうなりますか?
実現できない時間を提案する代わりに、その旨を明示します。実際には、あるゾーンの時間帯を広げたり勤務時間をずらしたりして対応することになります。でっち上げの答えより、正直な答えのほうが役に立ちます。
複数の日に一度に計画できますか?
バージョン1は一度に1日分を計画します。定期的な間隔の場合は、次のサマータイム変更の前後の境目の日を確認してください。固定の週間枠はそこで崩れるのが普通です。
このコレクションの一部 時間・日付・スケジュールツール
間違いを見つけましたか? 報告する — すべての修正を確認します.
Toolivaro編集チームが当社の方法論に基づいてレビュー済み 計算方法 · 編集方針