Skip to content

Replace days with dates, naming the exact dates to fetch - #17

Merged
chross22 merged 1 commit into
masterfrom
dates-argument
Aug 7, 2026
Merged

Replace days with dates, naming the exact dates to fetch#17
chross22 merged 1 commit into
masterfrom
dates-argument

Conversation

@chross22

@chross22 chross22 commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Why

days took day-of-month numbers and applied them to every requested month. That describes a sampling rule, not a set of dates. Survey dates are not a rule — they fall on the 3rd in January and the 17th in February, and no day-number selection expresses that.

Matching daily data to observations was the point of daily support, and days could not do it.

accessEnvDat(vars = "SST", dates = unique(observations$date), bounding_box = bb)

YYYYMMDD strings, YYYY-MM-DD strings, Date objects, and YYYYMMDD numbers are all accepted. Dates are sorted and deduplicated. A date the calendar does not have is an error naming it, since dropping it would fetch fewer days than were asked for and say nothing.

Because dates names the time steps, years and months are no longer required, and passing them alongside it is an error rather than two answers to one question with no rule for which wins.

A matching bug this exposed

detect_temporal_resolution() reads daily data from more than one day within a month. A set of survey dates — one per month — is indistinguishable from monthly data by that test, so matchData() would join by month and ignore the day. That is the opposite of why anyone passes dates.

accessEnvDat() knows which dataset it fetched, so it now records the step on the result and the detector trusts that over its heuristics. An explicit temporal_resolution still overrides both.

Caught by testing against the live API rather than by reading — the fetch looked right and the resolution was wrong.

One trap named in the error text

c() on a mixture of strings and Dates converts the Dates to days-since-1970 before the function sees them. Being told that 18310 is not a date is unhelpful without the cause, so that case is diagnosed specifically.

Verification

Live API: three dates on different days of three months fetch those days, come back as daily, and match observations on exactly those dates.

  YEAR MONTH DAY n      SST
  2010     1   3 1 6.900449
  2010     2  17 2 5.470718
  2010     3  26 3 5.130863
  • R CMD checkStatus: OK. Full suite green; the days test block is replaced by 13 dates tests covering input forms, sorting, dedupe, invalid dates, the c() coercion trap, the contradictions, and the recorded step.
  • Installed into both R 4.6.1 and 4.3.2.

Breaking

days is removed rather than deprecated — it landed today, is unreleased, and the two arguments mean different things, so an alias would be a rule masquerading as a date list.

🤖 Generated with Claude Code

`days` took day-of-month numbers and applied them to every requested
month, which describes a sampling rule rather than a set of dates. Survey
dates are not a rule: they fall on the 3rd in January and the 17th in
February, and no day-number selection expresses that. Matching daily data
to observations was the point of daily support, and `days` could not do
it.

`dates` names the dates instead, so the argument can come straight from
the observations being matched:

  accessEnvDat(vars = "SST", dates = unique(observations$date),
               bounding_box = bb)

YYYYMMDD strings, YYYY-MM-DD strings, Date objects, and YYYYMMDD numbers
are all accepted. Dates are sorted and deduplicated. A date the calendar
does not have is an error naming it, since dropping it would fetch fewer
days than were asked for and say nothing.

Because `dates` names the time steps, `years` and `months` are no longer
required, and passing them alongside it is an error rather than two
answers to one question with no rule for which wins.

Also fixes a matching bug this exposed. detect_temporal_resolution()
reads daily data from more than one day within a month, so a set of
survey dates - one per month - was indistinguishable from monthly data,
and matchData() would join by month and ignore the day. That is the
opposite of why anyone passes `dates`. accessEnvDat() knows which dataset
it fetched, so it records the step on the result and the detector trusts
that over its heuristics. An explicit temporal_resolution still overrides
both.

One trap worth naming in the error text: c() on a mixture of strings and
Dates converts the Dates to days-since-1970 before this ever sees them.
Being told that 18310 is not a date is unhelpful without the cause.

Verified against the live API: three dates on different days of three
months fetch those days, come back as daily, and match observations on
exactly those dates.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@chross22
chross22 merged commit 81798e6 into master Aug 7, 2026
5 checks passed
@chross22
chross22 deleted the dates-argument branch August 7, 2026 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant