epi_recipe(reference_date =)` is stored but never consumed by any date machinery

[docxology]

Channel: public issue · Severity: medium (API trap)

---

epi_recipe() accepts a reference_date argument documented as "the date to which all operations are relative" (R/epi_recipe.R:23-25 on HEAD 43b352f / main 7d8539b). It is stored on the recipe (:132-139) but never read: no step, layer, or workflow code accesses recipe$reference_date (grep over R/ finds only the constructor and the docs). Forecast/target dates continue to derive from metadata$as_of or max(time_value) (R/utils-latency.R:156-181; R/epi_workflow.R:99-110).

Repro (code-reading analysis; I don't have R available, so please confirm)

library(epipredict)

r <- epi_recipe(covid_case_death_rates,
                reference_date = as.Date("2021-06-01")) |>
  step_adjust_latency(death_rate_7d_av, method = "extend_ahead") |>
  step_epi_lag(death_rate_7d_av, lag = c(0, 7)) |>
  step_epi_ahead(death_rate_7d_av, ahead = 7)

r$reference_date           # stored: 2021-06-01
wf <- epi_workflow(r, parsnip::linear_reg()) |> fit(covid_case_death_rates)
forecast(wf)$predictions$forecast_date  # derived from as_of / max(time_value),
                                        # not from reference_date

Impact

Users setting reference_date expect latency adjustment and forecast/target-date bookkeeping to honor it; it is silently ignored. (For context, the recipe-level forecast-date work in #380/#433 seems related — perhaps this argument is a leftover from that effort.)

Suggested fix

Either consume recipe$reference_date in get_forecast_date()/get_forecast_date_in_layer() as the default forecast date, or remove the argument and soften the doc claim. Even a warning ("reference_date is currently stored for reference only") would prevent the trap in the meantime.