[robinvrd]

Summary

Add frontend-compatible DateTimeRange values throughout data-app authoring, from natural-language input and picker selection to URL state, operation validation, and SQL query bounds. Rolling windows remain relative; absolute selections preserve wall-clock fields as UTC-rebased dates.

• Add DateTimeRangePicker with natural-language entry, calendar selection, configurable presets, monitoring/analytics preset collections, and syntax help.
• Connect dateTimeRangeVariable() to generated controls, query parameters, and shared date-range contract policies for coverage, duration limits, and reporting timezone.
• Support optional previous-period comparison with synchronized execution bounds, metric labels, URL history, Clear, and Refresh. Keep existing calendar APIs supported.
• Add public API, typing, parser/SQL, and browser workflow coverage; update focused authoring documentation and generated reference.

Validation

• Rebased onto current main, preserving the external-link exports. Post-rebase build, type checking, and all 78 datetime tests passed.

• Full check reached 1,089 passing tests out of 1,090. The existing diagnostics clock test failed with Cannot fast-forward to the past and passed on isolated retry.

• Build, type checking, lint, style integrity, documentation/link checks, formatting, and generated reference checks passed.

• Package and starter checks passed separately after the test failure stopped the combined command.

• Reviewed with the requested thermo-nuclear-review recipe; fixed calendar draft interruption, comparison keyboard focus ownership, and reporting-timezone propagation findings.

Date semantics

Start bounds are inclusive and end bounds exclusive. Absolute picker dates encode wall-clock fields in UTC; backend reporting timezone interpretation remains separate. Comparison-enabled variables produce validated execution snapshots while retaining the relative selection for URL state.

Preview

[albert20260301]

One validation gap remains in parseDateTimeRange(): for bounds sharing an anchor and using only fixed offsets, the computed duration is checked against maxRangeDays but never checked to be positive. For example:

const period = dateTimeRangeVariable({
  key: 'period', defaultValue: '1h', maxRangeDays: 1,
});
period.valid({
  from: { anchor: 'RELATIVE_ANCHOR_NOW', offset: [{ amount: 1, unit: 'HOUR' }] },
  to: null,
}); // true: start is one hour AFTER end

A zero offset also returns true. Without an optional shared contract, the picker and variableInput() use this parser and accept these ranges; SQL binding serializes them rather than rejecting them. This case is independent of timezone or reference time. Reject a known duration <= 0, while continuing to leave calendar-dependent/mixed-bound ordering to reporting-zone resolution, and add a public regression for the variable/server path.

Local build/types/lint, 60 core datetime tests and 42 browser/filter workflows pass on the original head. I reviewed the subsequent whitespace-regex correction on 022caa8 and its parser tests pass; fresh full CI still needs to complete. The old CodeQL regex findings should be reassessed on that new head, not treated as proof of a reachable tab-input slowdown: parser input is normalized first.

[albert20260301]

The correction on 5980acd resolves the validation blocker: known zero/negative fixed-offset durations are rejected even without a shared contract, and public variable/server regressions verify rejection before querying. Standalone bound parsing remains supported.

Local build/types/lint, 67 core datetime tests and 32 Chromium datetime/comparison/external-link tests pass. Required source/packed CI and CodeQL are now green on this head.

Merging adds the reviewed datetime range and comparison support; published package availability still requires the human release process.