Markdown for LLMs

Time: the date of law, a rule window, and an edition

The source Markdown for this article. Copy it into your assistant or download it as a text file.

# Time: the date of law, a rule window, and an edition

Law answers as of a date. The same case before a norm's entry into force
and after it gets different answers, and neither is a mistake. Dates are
the corpus's most frequent literal: over eight thousand in 443 packages
out of 508 (measured 05.09.2026). And the most frequent source of the
"why is law silent" question: the rule is written correctly, the facts
are fed, yet the answer is `NEITHER`, because on this date the rule does
not yet exist.

This page holds three ways to date a norm and one axis they all check
against. The Archive of Veliky Ustin adopts a new edition of the rules
from 2027.

```law
language "law.core" version "0.2";
package tutorial.archive version "0.4.0";
namespace "urn:law:tutorial:archive";

entity Person;

source ARCHIVE_RULES {
    kind municipal_act;
    jurisdiction VELIKY_USTIN;
    number "2026-14";
}

edition ARCHIVE_RULES_2026_RU of ARCHIVE_RULES {
    language ru;
    officiality official;
    adopted @2026-01-15;
    in_force [@2026-02-01, infinity);
}

edition ARCHIVE_RULES_2027_RU of ARCHIVE_RULES {
    language ru;
    officiality official;
    adopted @2026-11-20;
    in_force [@2027-01-01, infinity);
}

fragment ARCHIVE_RULES_2027_P6 in ARCHIVE_RULES_2027_RU {
    kind paragraph;
    locator "paragraph/6";
    text ru official """Исследователь, состоящий в реестре, вправе заказать оцифровку документа.
""";
    content_hash "sha256:aeb29654149aeea7af992a44563af55ae16c9bde3177074ad72334bd3d201756";
}

relation in_researcher_registry(p: Person) kind institutional;
relation accredited(p: Person) kind institutional;
relation briefing_required(p: Person) kind institutional;
relation may_order_digitization(p: Person) kind institutional;
relation reader_card_issued(p: Person, on: Date) kind empirical { key(p); }
relation card_reissue_required(p: Person) kind institutional;
```

The quoted fragment reads: "A researcher listed in the registry may order digitization of a document."

## The axis everything looks at

A case context holds four axes, none taken from the system clock:
`legal_time` — the date on which the applicable law is selected;
`decision_time` — the moment the answer is issued; `knowledge_time` —
the boundary of data known to the system; `timezone` — the zone. All
dated things on this page check against the first axis. An answer issued
in March 2027 on a June-2026 event counts under June-2026 law — that is
the difference between `decision_time` and `legal_time`, and confusing
them is costly.

A scenario test sets the axes for each scenario separately, so the page
speaks in pairs below: one case, two dates of law.

## A rule window

From 1 January 2027, rare-collections room access requires a briefing
first. The norm gets its own validity window — the `effective` clause.

```law
rule BriefingRequired2027 strict {
    effective [@2027-01-01, infinity);
    for p: Person;
    when in_researcher_registry(p);
    then briefing_required(p);
}
```

| `legal_time` | `briefing_required` | `applied(BriefingRequired2027)` |
|---|---|---|
| 2026-06-01 | `NEITHER` | no |
| 2027-06-01 | `TRUE_ONLY` | yes |

`effective` is an applicability condition, not a premise.
Before the window the rule did not "fire with a false condition": it
took no part in the computation at all, and `why_not` will name it
a candidate with the `NOT_APPLICABLE` status, not "condition not
established". The distinction shows in the test too: the `applied(…)`
observation answers "no" before the window and "yes" inside it.

The first test is from the page you are reading, byte for byte:

```law
test "до окна effective правило не участвует" {
    given {
        context {
            decision_time @2027-03-01T09:00:00+05:00;
            knowledge_time @2027-03-01T09:00:00+05:00;
            legal_time @2026-06-01;
            timezone "Asia/Almaty";
        }
        assert in_researcher_registry(entity_ref("urn:tutorial:ivanova")) {
            id "assert-reg";
            origin case_input;
        }
    }
    evaluate truth(briefing_required(entity_ref("urn:tutorial:ivanova")));
    expect truth_status == NEITHER;
    expect evaluation_status == COMPUTED;
    expect not applied(BriefingRequired2027);
}
```

The test name reads: "Before the `effective` window the rule takes no part."

Note: `decision_time` in both scenarios is March 2027, and only
`legal_time` changes. The answer date does not select the law.

## A rule dated by edition

The right to order digitization appears in the 2027 edition. The norm
has no `effective` of its own: the anchor leads to that edition's
fragment, and its `in_force` decides the rule's participation.

```law
@source(ARCHIVE_RULES_2027_P6)
rule DigitizationOrder strict {
    for p: Person;
    when in_researcher_registry(p);
    then may_order_digitization(p);
}
```

| `legal_time` | `may_order_digitization` | Document |
|---|---|---|
| 2026-06-01 | `NEITHER` | issue `EDITION_NOT_APPLICABLE` |
| 2027-06-01 | `TRUE_ONLY` | — |

This is the corpus's ordinary form: `in_force [@…, infinity)` on the
edition and rules without their own window, dated by anchors. A rule is
removed only when **all** editions it is anchored to are inapplicable on
the date of law; the document carries one issue per edition, and
`why_not` answers with the same `NOT_APPLICABLE`. An edition with
neither `in_force` nor another applicability event dates nothing: "law
is not dated" is an answer, not "not in force".

When to choose what. `effective` on a rule — when one article enters
into force apart from the act: the Social Code of RK holds nine such
windows from 1998 to 2023. An edition — when the act is dated as a whole;
then a window on the rule is spare and will sooner or later diverge from
`in_force`.

## A date in the body

The third way dates no norm at all but compares a fact's date. Tickets
issued before the 2026 rules entered into force are subject to reissue:
this is a condition on a fact, and it lives in the body.

```law
rule OldCardReissue strict {
    for p: Person;
    for on: Date;
    when reader_card_issued(p, on) and on < @2026-02-01;
    then card_reissue_required(p);
}
```

| Ticket issued | `card_reissue_required` |
|---|---|
| 2025-12-01 | `TRUE_ONLY` |
| 2026-03-01 | `NEITHER` |

`legal_time` is irrelevant here: the rule applies on any date of law,
while the fact's date decides. So the corpus also writes retroactivity:
by comparing the event date in the body, not by a window.

## A fact is dated too

A norm is dated by law, a fact by the world. A case statement carries
a `valid` window: when it holds of the legal state. An
accreditation issued from 2027 does not enter supports in June 2026.

```text
assert accredited(entity_ref("urn:tutorial:ivanova")) {
    id "assert-acc-2027";
    origin case_input;
    valid [@2027-01-01, infinity);
}
```

| `legal_time` | `accredited` | Document |
|---|---|---|
| 2026-06-01 | `NEITHER` | issue `ASSERTION_OUTSIDE_VALID` |
| 2027-06-01 | `TRUE_ONLY` | — |

The window checks against the same `legal_time` axis; `evaluation_status`
stays `COMPUTED`, because the computation took place — just without this
fact. Two more fact times, `observed` and `recorded`, answer another
question: when observed and when entered into the system. They compare
with nothing but each other.

## Three compiler refusals

A rule holds one window. A second `effective` in the same block is
a refusal, not an intersection:

```text
error LDC-E1329: повторная клауза `effective` в правиле — не более одной на
блок (§94, E-0114)
```

The diagnostic reads: "repeated `effective` clause in a rule — at most one per block".

A window boundary is a date, an instant, or `infinity`. The compiler does
not accept a name instead of a date, however telling it seems to you:

```text
error LDC-E1305: граница effective — дата/instant или infinity
```

The diagnostic reads: "an `effective` boundary is a date/instant or `infinity`".

`Date` and `Instant` are different kinds, and they cannot be compared.
Replace the date in `OldCardReissue` with the instant
`@2026-02-01T00:00:00+05:00`:

```text
error LDC-E2108: «<»: несравнимые виды Date и Instant — §57/§48 требуют
совпадения видов, неявных конверсий нет
```

The diagnostic reads: "'`<`': incomparable kinds Date and Instant — kinds must match, no implicit conversions".

No implicit conversions on purpose: midnight of 1 February in Almaty and
in Greenwich are different instants, and which of them is "the date" is
a policy question, not an arithmetic one. Write the threshold in the
argument's kind: date to date, instant to instant. All three refusals
belong to the language.

## Why law stays silent

When a norm yields `NEITHER` on any case, dates are the first thing to
check. There are three: the case's `legal_time`, the rule's `effective`,
and the `in_force` of the edition the `@source` leads to. A stub edition
with a future `in_force` removes all rules anchored to it at once, and
`check` will not tell: statically all is correct; removal happens at
runtime. `why_not` names the candidate and its status — that is the first
tool, not the last.

## Next

The `effective` window says when a norm applies. When the norm's
**addressee** must act — by which date to perform, within which term to
answer — is another machine: the calendar, the terms-counting policy,
and the `deadline` query; the tutorial on terms is devoted to it. And in
the duty
tutorial the window will appear on the position itself: the "from 2027"
milestone stays in the rule's `effective`, while the aim's window counts
from the event. Both pages are in the track plan but not yet written.

The exercise for this page is [/tutorials/exercise-time/](/tutorials/exercise-time/).