# Round date and weather

Core's `ERR_EnvironmentService` applies optional date and weather selections once during server-side round preparation, immediately before the existing clock service. The native time/weather manager owns simulation and replication. There is no environment tick, local preview, player-health modification or periodic reset. Repeated starts retain the initial selection; a stopped service cannot restart.

Defaults preserve the authored world. Old valid settings files without `startDateCode` and `weatherProfile` acquire zero values in memory, are not rewritten during loading, and retain every existing supported value. An explicit successful save writes the expanded schema using the existing validated temporary-file/backup flow. Present invalid environment values reject the file rather than silently defaulting.

Administrators use:

- `/esc mission date show` and `/esc mission date set YYYY-MM-DD` (1900–2050 inclusive), or `set authored`.
- `/esc mission weather show` and `/esc mission weather set authored|clear|overcast|rain` (`rainy` is accepted as an alias).

These commands save next-round choices. They report the current native environment separately and do not apply saved changes to the running world. Date validation covers month lengths and Gregorian leap years, including non-leap 1900 and leap 2000. The native manager also validates an explicit date before applying it.

`weatherProfile` values are 0 authored, 1 Clear, 2 Overcast and 3 Rainy. An explicit profile uses the native replicated `ForceWeatherTo` route and loops that weather family. The service validates that the named vanilla state and transition manager exist before changing the date or issuing a request. It verifies the requested current/next state and looping flag. On rejection it attempts to restore the previous date and weather family/looping before startup reports failure. This is not a snapshot of every native transition queue or variant parameter. No UI preview API is used.

A fixed profile selects a family deterministically; cloud variants, wind and other native weather behavior still follow vanilla rules. Existing authored wind/fog overrides are retained. The `authored` setting makes no weather request and preserves the scenario's original weather evolution. Visual intensity, remote replication, manual visibility and long-running transitions still require runtime acceptance.

`startDateCode` is an internal compact integer: `(year - 1900) * 10000 + month * 100 + day`, with 0 meaning authored. For example, 1989-06-01 is 890601. It intentionally stays below 1,501,232, exactly representable by the existing settings reader's floating-point JSON path. A full `YYYYMMDD` number can exceed single-precision exact integer range and corrupt odd dates. Use the natural date command rather than constructing codes by hand.

## Validation

`tests/test_environment_policy.py` executes the actual settings validator and production parsing/formatting functions through the existing C++ policy harness. It compares calendar boundary cases across every supported year against Python's independent `datetime` calendar, tests malformed dates and names, and checks defaults and native family names. Existing migration tests cover the added defaults and bounds. These checks pass; they are not Enforce compilation.

The opt-in WORKBENCH `ERR_NativeEnvironmentProbe` uses a dedicated test settings file, preserving the actual mission settings. It tests legacy loading without rewrite, exact odd date-code serialization, save rejection, unauthorized commands, next-round command behavior and no world mutation from saves. It then temporarily uses fresh service instances to select Clear, Overcast and Rainy with explicit/leap/authored dates, waiting at least one 500ms smoke tick per state. It verifies start idempotency, stopped-service rejection and unchanged clock/progression settings. Before completing it restores the original date, weather family and looping mode. Native transition-queue timing and cloud-variant history are not restored exactly; this is an isolated case that ends with a test-requested round reset. Native compilation and execution remain pending centralized hidden and muted testing.

## Native evidence

[063559](evidence/native-2026-09-19-063559/report.json) completed 67 combined environment/catalog assertions with no script/VM failures and no engine errors. Exact native catalogs retained medical and radio entries; all three weather families and a leap date applied without resetting the clock. Defaults and next-round settings behavior were exercised. This one-round development result does not establish multiplayer replication or repeated-restart reliability.