[CaffeinatedCoder]

Closes #506

Problem

A YearMonthRange is stored as a month-aligned daterange, and a YearMonth you pass in is sent as the first day of its month. In a query, UpperBound() read upper(x) - 1, the last day of the last month. That loads as the right month, so projections agreed with memory and the tests that project the bound passed. In a filter it compared unequal to the month, and greater:

On [2026-01,2026-01]	Memory	Query
UpperBound() == 2026-01	true	false
UpperBound() > 2026-01	false	true
Clamp(2026-02) == 2026-01	true	false

RangeSet<YearMonthRange, YearMonth>.UpperBound() and Clamp read the same helper. Clamp on YearMonthRange runs as SQL since #486 (10.4.0, 11.0.0-preview.1), and UpperBound() since the type's EF mapping.

Change

• CoarseUpperBound (new, internal) and IRangeTypeDefinition.CoarseUpperBound. It holds the span of one element as an interval, and the element an inclusive infinity stands for. YearMonthRangeTypeDefinition sets ("1 month", 9999-12).
• ValueRangesMethodCallTranslator.UpperBoundFunction: on such a type, CoarseUpper writes CASE WHEN NOT isfinite(upper(x)) THEN DATE '9999-12-01' ELSE CAST(upper(x) - INTERVAL '1 month' AS date) END. 9999-12 ends on LocalDate.MaxIsoValue, which Npgsql writes as infinity, and no interval steps back from that. With Npgsql.DisableDateTimeInfinityConversions the bound is a finite 10000-01-01, and the interval reaches 9999-12-01 on its own. Other types produce the same SQL as before.
• Docs: Store a YearMonthRange (efcore.md) says how the bound compares, and the discrete-bounds note points there. architecture.md says how it works. Migration from v10.x gets a bullet and the section Check YearMonthRange upper bounds compared in queries. A ### Breaking line in 11.0.0-preview.1 of the root and EF Core NodaTime changelogs.
• Oracles: claim E88. YearMonthBoundParityTests is registered as a differential oracle, with two seeds.

It changes answers, so it's labelled silent. On 10.x it ships in 10.4.0 under ### Changed answers (port issue to follow).

Tests

• ClampDomainParityTests now compares Clamp(@p) with every point by ==, < and > in a filter, on all 13 range types. Before, it compared with the same point only, which never reaches the clamped bound. With the fix reverted, YearMonthRange has 420 disagreements, and the other twelve types agree.
• YearMonthBoundParityTests (new, integration): LowerBound() and UpperBound() of the range and its RangeSet, over every shape between five months (9999-12 among them), compared with each month by ==, < and > in a filter against memory over the loaded rows.
• YearMonthUpperBoundTests (infinity-disabled project): UpperBound() == month at 2026-01, 9999-11 and 9999-12, with the conversions off.
• NodaQueryTranslationTests: the two asserts on the old upper(x) - 1 now assert the new SQL.
• Proved by reverting:
  • Without the dispatch line, all three live tests fail.
  • oracles.cs seeds yearmonth-upper catches both seeds: the day step in both oracles, and the dropped infinity arm in YearMonthBoundParityTests. Clamp can't reach that arm, because no month lies above 9999-12.
• Full suite green on PostgreSQL 16, and the three YearMonth classes on PostgreSQL 18.

🤖 Generated with Claude Code