DueFilter

Which due values match, one window per temporal type ([ADR-183]).

Koru stores three temporal types and never one with a nullable timezone, so a filter says which of them it is asking about. The windows compose with OR - "everything due this week, however it was set" is genuinely two questions asked of two kinds of value - and a row of a type this filter did not name simply does not match.

What this deliberately does not do is fold one type onto the other. The shape it replaced took a single bound and cut instants at the UTC day boundary, which is wrong by a day for a third of the planet: 15:00Z on September 2 is already September 3 in Tokyo. A caller that wants a zone-exact window computes its own millisecond edges, because the caller is the layer that knows which zone the person is asking in.

Naming neither window is refused: it is a question nobody asked, and answering "everything" would be a guess.

[ADR-183]: ../../../docs/decisions/ADR-201-225.md#adr-206-timemodel--koru-has-three-temporal-types-not-one-with-a-nullable-timezone

Type object

Shape

Field	Type	Description
dates	DateWindow or null	Compared against dues stored as a calendar date - and against floating wall clocks, whose day needs no zone to read. Default `null`
instants	InstantWindow or null	Compared against dues stored as a zoned instant. Default `null`

Example

{
  "dates": {
    "after": "string",
    "before": "string"
  },
  "instants": {
    "after_ms": 0,
    "before_ms": 0
  }
}

The contract has no example values, so example bodies are generated from each schema: every field is shown with a placeholder of its type.

Generated from contract version 1. Last updated November 12, 2026.