Fix generated calendar date filter semantics

CHANGELOG.md

@@ -14,6 +14,35 @@ This file is the authoritative user-facing release chronology. The former
 [release-notes ledger](docs/archive/2026/graphql-orm-release-notes.md) is retained
 for historical context.
 
+## 0.30.0 - 2026-08-31
+
+Companion macros crate: `graphql-orm-macros` **0.30.0**. Backend-neutral
+semantic owner: `graphql-orm-operation-catalog` **0.4.0**.
+
+- Corrected generated calendar filters to use sargable half-open timestamp
+  ranges. `IsToday`, `InFuture`, `RecentDays`, `WithinDays`, and relative upper
+  bounds now include or exclude complete calendar dates as documented without
+  applying a function to the persisted column.
+- Added one recursive `DatabaseFilter::validate` execution seam. Generated
+  filters reject zero, negative, or excessive calendar spans, excessive signed
+  offsets, malformed or reversed ranges, and GraphQL `Between` inputs missing
+  either required bound. Invalid direct rendering produces a false predicate;
+  query execution returns `INVALID_INPUT` before database work.
+- Made SQLite spatial fallback evaluate every date operator with one
+  deterministic UTC calendar anchor and SQL three-valued NULL semantics across
+  direct, `And`, `Or`, and `Not` expressions.
+- Corrected semantic date-field detection to take precedence over the Rust
+  backing type. Date fields now advertise the exact generated `DateFilter`
+  grammar, including calendar and relative operators and excluding unsupported
+  membership and string operators.
+
+PostgreSQL derives today from the connection session's `CURRENT_DATE`; SQL
+Server uses the server-local date from `GETDATE()`; SQLite uses UTC through
+`date('now')`, with the same UTC basis in spatial fallback. Exact comparison
+values remain unchanged and unnormalized. No table, column, constraint, or
+stored-data migration is required. Regenerate SDL, semantic catalogues, and
+dependent fingerprints.
+
 ## 0.29.0 - 2026-08-31
 
 Companion macros crate: `graphql-orm-macros` **0.29.0**.

Cargo.toml

@@ -37,10 +37,10 @@ cynic-parser = { version = "=0.11.2", features = ["pretty"] }
 futures = "0.3"
 getrandom = "0.3"
 graphql-composition = "=0.12.2"
-graphql-orm = { path = "crates/graphql-orm", version = "0.29.0", default-features = false }
+graphql-orm = { path = "crates/graphql-orm", version = "0.30.0", default-features = false }
 graphql-orm-ai-tool-profiles = { path = "crates/graphql-orm-ai-tool-profiles", version = "0.10.2" }
 graphql-orm-backup = { path = "crates/graphql-orm-backup", version = "0.7.2", default-features = false }
-graphql-orm-operation-catalog = { path = "crates/graphql-orm-operation-catalog", version = "0.3.0" }
+graphql-orm-operation-catalog = { path = "crates/graphql-orm-operation-catalog", version = "0.4.0" }
 graphql-orm-router-protocol = { path = "crates/graphql-orm-router-protocol", version = "0.2.1" }
 graphql-orm-storage = { path = "crates/graphql-orm-storage", version = "0.6.2", default-features = false }
 hive-router = "=0.0.87"

MIGRATION.md

@@ -13,6 +13,44 @@ supersedes: []
 `graphql-orm` is distributed from GitHub only. Use a reviewed full 40-character commit in `rev`;
 neither the runtime nor macros crate is published to crates.io.
 
+## 0.29.0 to 0.30.0: checked calendar-date filters
+
+Adopt `graphql-orm` and `graphql-orm-macros` 0.30.0 together from one reviewed
+full Git revision. Backend-neutral semantic consumers must adopt
+`graphql-orm-operation-catalog` 0.4.0 from that revision. The AI tool-profile
+package remains 0.10.2; rebuild its generated capabilities against the new
+semantic catalogue.
+
+Generated calendar predicates now use half-open ranges over the persisted
+column: today is `[today, tomorrow)`, future begins at tomorrow, the past ends
+at today, `RecentDays(N)` includes exactly today plus `N - 1` preceding dates,
+and `WithinDays(N)` includes exactly `N` dates beginning today. `LteRelative`
+is inclusive through its selected calendar date by rendering an exclusive
+next-date upper bound. Ordinary `Eq`, `Ne`, `Lt`, `Lte`, `Gt`, and `Gte`
+continue binding the supplied value without normalization.
+
+`DateRangeInput.start` and `DateRangeInput.end` are now required `String`
+fields. Update Rust struct literals that supplied `Option<String>`. Both bounds
+must be parseable date/timestamp values and start must not follow end.
+`RecentDays` and `WithinDays` accept 1 through 36,600; signed relative offsets
+accept -36,600 through 36,600. Generated query execution validates recursively
+and returns `INVALID_INPUT` before database work. Handwritten `DatabaseFilter`
+implementations remain source compatible because `validate` has a permissive
+default; implement it when a custom filter has structured invariants.
+
+The meaning of today remains backend-owned and is now internally consistent:
+PostgreSQL uses session `CURRENT_DATE`, SQL Server uses the server-local date
+from `GETDATE()`, and SQLite uses UTC `date('now')`. SQLite's in-memory spatial
+fallback captures one UTC date per filtering pass and does not push
+clock-dependent predicates into its SQL prefilter. This release does not add a
+cross-backend application-timezone setting or normalize exact input strings.
+A future typed date/time input and context-bound calendar-clock design requires
+separate compatibility review.
+
+Date semantic metadata and catalogue fingerprints change. Rebuild reviewed
+catalogues, automatic query capabilities, and retained bindings. There is no
+database schema, stored-data, backup, or migration-history change.
+
 ## 0.27.0 to 0.29.0: computed/relation ordering and complex relation composition
 
 Computed fields can join generated ordering without a handwritten query:

README.md

@@ -42,12 +42,12 @@ schema changes explicitly.
 
 Packages are distributed from this repository, not crates.io. Pin the reviewed
 release revision, not a moving branch or tag. The current coordinated
-`graphql-orm` version is 0.29.0. Replace the placeholder below with the final
+`graphql-orm` version is 0.30.0. Replace the placeholder below with the final
 reviewed full SHA for the release:
 
 ```toml
 [dependencies]
-graphql-orm = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.29.0", default-features = false, features = ["sqlite"] }
+graphql-orm = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.30.0", default-features = false, features = ["sqlite"] }
 ```
 
 Choose exactly the backend support needed by each service. Cargo can unify

crates/graphql-orm-macros/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "graphql-orm-macros"
-version = "0.29.0"
+version = "0.30.0"
 edition = "2024"
 authors = ["Toby Martin"]
 description = "Procedural macros for async-graphql and ORM-backed entities, relations, and CRUD operations."

crates/graphql-orm-macros/README.md

@@ -16,13 +16,13 @@ macro/runtime versions aligned:
 
 ```toml
 [dependencies]
-graphql-orm = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.29.0", default-features = false, features = ["sqlite"] }
+graphql-orm = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.30.0", default-features = false, features = ["sqlite"] }
 ```
 
 Direct use is supported for tooling that needs the macro package:
 
 ```toml
-graphql-orm-macros = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.29.0", default-features = false, features = ["sqlite"] }
+graphql-orm-macros = { git = "https://github.com/Dastari/graphql-orm.git", rev = "<reviewed-full-40-character-commit-sha>", version = "0.30.0", default-features = false, features = ["sqlite"] }
 ```
 
 The direct dependency still requires a compatible `graphql-orm` runtime in the
@@ -135,5 +135,11 @@ mapping and target entity table. Entities that also have handwritten complex fie
 handwritten impl so generated relations are flattened into the same
 `ComplexObject` surface.
 
+Generated `DateFilter` fields use sargable half-open calendar ranges and a
+recursive validation path shared by GraphQL and programmatic queries. Between
+bounds are required; calendar spans and signed relative offsets are bounded.
+The generated semantic operator set follows the date grammar rather than the
+field's Rust backing type.
+
 See [core runtime documentation](../graphql-orm/README.md),
 and the [macro and attribute reference](../../docs/reference/graphql-orm/macros-and-attributes.md).