前回の記事の、あの変な括弧
前回、営業時間の話の中でこういう表記を何度か使った——[開場, 閉場)。
左が角括弧で、右が丸括弧。非対称である。誤植に見えたかもしれない。すみません、先に言っておくべきだった——これはわざとで、しかもスケジュールの世界では、この非対称な括弧がかなり働き者だという話を今日はしたい。数式は出てこない。
「9 時から 15 時まで」には、答えのない問いがある
窓口の営業時間が「9 時から 15 時まで」だとする。では 15 時 0 分 0 秒ちょうどに届いたリクエストは、営業中か、営業外か。
日常の言葉はこれを決めていない。人間どうしなら「どっちでもいい」で済む。だがシステムはどちらかに決めないと動けない——決めずに作ると、実装した人ごとに答えが割れて、境界の 1 秒に届いたデータだけ二重に処理されたり、どこにも処理されなかったりする。境界のバグは再現条件が「ちょうどその瞬間」なので、めったに起きず、起きたときは誰も原因にたどり着けない。
そこで先人が用意した書き方が、あの非対称な括弧である。
- [ ——角括弧の側は、含む。9:00:00 ちょうどは営業中。
- ) ——丸括弧の側は、含まない。15:00:00 ちょうどは、もう営業外。
含む側と含まない側を半分ずつ持つので半開区間と呼ばれる。「[9:00, 15:00)」は「9 時ちょうどから、15 時の直前まで」を一文字も曖昧さなく言い切る書き方だ。
なぜ端を「混ぜる」のか——23:59 問題
両方含む書き方(両閉じ)にしなかったのには理由がある。両閉じで連続した時間を埋めようとすると、こういう書き方をする羽目になる:
午前の部: 9:00 〜 11:59 午後の部: 12:00 〜 17:59 夜間受付: 18:00 〜 23:59
見覚えがあると思う。この書き方には二つの問題が埋まっている。ひとつ、11:59 と 12:00 の間の 59 秒はどちらの部でもない——隙間である(「11:59:59 まで」と書き直しても、今度は残りの 1 秒が落ちる。精度を上げるほど狭くなるが、ゼロにはならない)。ふたつ、この隙間の幅は時刻の精度に依存する——分で書くか秒で書くかミリ秒で書くかで、落ちる量が変わる。仕様が精度の都合に振り回されている。
半開区間で書き直すと:
午前の部: [9:00, 12:00) 午後の部: [12:00, 18:00) 夜間受付: [18:00, 24:00)
前の区間の「終わり」と次の区間の「始まり」が同じ点になり、その点は必ず次の区間に属す。重ならず、漏れず、精度の話が消えた。定規の目盛りと同じである——0cm から 1cm までの 1 センチと、1cm から 2cm までの 1 センチは、1cm の線を取り合ったり譲り合ったりしない。
コツは一つだけ: 「終わりの時刻」を書くのをやめて、「次が始まる時刻」を書く。 23:59 と書いた瞬間に 1 分落ちる。24:00(= 翌日の 0:00)と書けば、何も落ちない。
Kairos は、端という端がこの規約でできている
私が設計しているスケジュール定義言語 Kairos は、時間の区間をすべて半開で統一している。たとえば評価範囲。「1 月 5 日から 1 月 8 日まで」の毎日を評価すると:
everyDay
2026-01-05 2026-01-06 2026-01-07
1 月 8 日は出ない。範囲 [1/5, 1/8) の終端は「含まない」側だからだ。最初は不便に見えるかもしれないが、これのおかげで「今週ぶん [月曜, 翌月曜) を評価し、来週ぶんを [翌月曜, 翌々月曜) で評価する」と書いたとき、月曜が二重に発火することも、日曜の夜が落ちることも、構造的にありえない。運用でスケジュールを分割評価する場面(第 8 弾の撃ち漏らし列挙がまさにそれ)では、この保証が効いてくる。
終了日を 2026-01-09 に書き換えて再評価すると、1/8 が現れる。「終わりではなく、次の始まりを書く」の感覚がつかめると思う。
同じ規約が全部の粒度を貫いている。「1 月 5 日」という日は [1/5 の 0:00, 1/6 の 0:00) の区間だし、前回の営業時間 [開場, 閉場) もそうだった——だから 15 時ちょうどの正時は発火せず、冒頭の「15:00:00 ちょうどは営業中か」には営業外という決定的な答えが返る。誰が実装しても、何年後に評価しても、同じ答えになる。
まとめ
- [a, b) は誤記ではない——「a は含む・b は含まない」の半開区間
- 「23:59 まで」の書き方は精度依存の隙間を生む。終わりの時刻ではなく、次が始まる時刻を書くと、重なりも漏れも構造的に消える
- Kairos は評価範囲・日・営業時間、端という端をこの規約で統一している——境界の 1 秒のバグが「実装した人ごとの答え」ではなく「言語の答え」になる
次にどこかで非対称な括弧を見かけたら、誤植ではなく「継ぎ目の設計」だと思って読んで もらえたら嬉しい。
Kairos は設計中のスケジュール定義言語です。仕様と参照実装は GitHub で公開しています。
コメント