fix(ogc): read each side of a "start/end" interval string like the list form

[bhaskargurram-ai]

Follow-up named in #441 ("a single string containing / is still sent unchanged, so time="garbage/.." reaches the service unvalidated").

Problem

_format_api_dates returned any single string containing / unchanged. As a result, the same range spelled the two documented ways could select different data:

input (TZ=America/Denver)	sent before
time=["2024-01-01T10:00:00", None]	2024-01-01T17:00:00Z/..
time="2024-01-01T10:00:00/.."	2024-01-01T10:00:00/.. (no local-to-UTC conversion)
daily, time=["2024-01-01T10:00:00Z", "2024-02-01T00:00:00Z"]	2024-01-01/2024-02-01
daily, time="2024-01-01T10:00:00Z/2024-02-01T00:00:00Z"	sent with times
time="not-a-date/also-bad"	sent unchanged; the service answers 400 without naming the argument
time="2024-01-01T00:00:00Z/"	sent unchanged; daily answers 400, continuous 500

Change

• A single string containing / is split on that /, and each side is formatted exactly like an element of the two-value list form. Sides get the same parsing, naive-local-to-UTC and offset-to-Z conversion, and date truncation for date-only collections.
• An unreadable side raises the existing ValueError (time could not be read as a date or datetime: 'not-a-date'. ...) before any request is sent.
• An empty side is an open bound (..), and "../.." means no date filter, as [None, None] does.
• One side may still be an ISO 8601 duration paired with an instant ("2024-01-01/P7D", "P7D/2024-01-08"), sent unchanged as before.
• Any other shape raises ValueError naming the argument: three sides, two durations, or a duration with an open end.
• A lone duration such as "P7D" is unchanged.
• NEWS entry marked Behavior change.

One question for review: while testing I found that api.waterdata.usgs.gov/ogcapi/v1 rejects both duration-interval forms (daily time=2024-01-01/P7D gives 400 "Invalid datetime format", time=P7D/2024-01-08 gives 400 "Invalid ISO 8601 duration"; the same for continuous with PT2H). This PR keeps passing them through, so nothing that worked before changes. If you would rather reject them locally, it is a small change to _format_interval.

Tests

• tests/waterdata_utils_test.py:
  • each interval string formats the same as the equivalent list (naive start/end, offset, space-separated, date-only truncation, empty end);
  • per-side formatting, including start/duration and duration/end;
  • "../.." gives None;
  • six rejected shapes, each naming the argument.
• tests/waterdata_test.py: get_daily(time="not-a-date/also-bad") raises and sends no request.

The new cases fail on main and pass with this change. The full offline suite passes under TZ=UTC and TZ=America/Chicago, coverage is 98.99% against the 98.9 ratchet with dates.py at 100%, and ruff check, ruff format --check, mypy, lint-imports, xenon and complexipy are clean.

This touches the same module as #442, but in a different part of _format_api_dates. The only conflict between the two branches is the top entry in NEWS.md.

---

Maintainer update (2026-10-12)

The branch is now three commits: the original commit above, unchanged; a merge of main; and one commit with the maintainer's edits. Those edits change several points above.

• Duration sides are rejected. The services reject both duration-interval forms with HTTP 400, as the question above found, so "2024-01-01/P7D" and "P7D/2024-01-08" now raise ValueError naming the argument. A lone duration ("P7D") is unchanged.
• The open-start form depends on the API. The NGWMN and STAC firewalls reject any ../ with HTTP 403, so get_water_level(datetime=[None, end]) and get_ratings(time=[None, end]) always failed. They now send an empty start (/end), which both services treat as open. Water Data keeps .., because it rejects /end with HTTP 400. The form is set by OgcDialect.open_start.
• Naive dates are UTC, as in pandas. A naive date or time is UTC instead of the machine's local time (get_nearest_continuous already did this), and an aware value is converted to UTC, including in date-only collections. With local time, parsing the string like the list form would have made the documented time="2024-03-01/2024-03-02" start at 06:00Z in Chicago. Checked live on a machine set to Chicago time: it now sends 2024-03-01T00:00:00Z/2024-03-02T00:00:00Z.
• Fractional seconds are kept instead of truncated, because truncating one changed a closed bound. The Water Data, NGWMN and STAC services all accept them (checked 2026-10-12).
• More inputs are accepted. A minute-precision time (2024-01-01T10:00Z) and spaces around the / are accepted again; both were previously sent unchanged and worked.
• Docs and NEWS.
  • The time-conventions guide states the rule for date arguments.
  • The NEWS entry is marked Behavior change, dated by the day it lands, and placed above fix(ogc): send Water Data list filters and CQL2 JSON filters correctly #446's.
  • The docstrings and the duration test IDs are corrected.

A new test checks the UTC rule under TZ=America/Chicago; it fails on the old code. The full offline suite (1313 tests) passes under TZ=UTC, TZ=America/Chicago and TZ=Asia/Kolkata, and so do ruff, mypy, the pre-commit gates and the related live tests.