Activity

1. brookslogan

   changed the title [-]Make `adjust_latency` work or give nicer debug messages[/-] [+]Make `adjust_latency` work or give nicer debug messages (on weekly data?)[/+] on Feb 10, 2026
2. brookslogan commented on Feb 10, 2026

   

   brookslogan

   on Feb 10, 2026

   Last edited by brookslogan

   ContributorAuthor

   More actions

   One attempt to work around by lying about the as_of [though it'd be better to do something similar by shifting the time_value and keeping the as_of accurate] generates error or output+warning:

   suppressPackageStartupMessages({
   library(epidatr)
   library(epiprocess)
   library(epipredict)
   library(dplyr)
   })
   cce <- covidcast_epidata()
   as_of <- as.Date("2026-01-21")
   nhsn_flu_tbl <- cce$signals$"nhsn:confirmed_admissions_flu_ew"$call("state", "*", "*", as_of = as_of)
   nhsn_flu_edf <- nhsn_flu_tbl %>%
     select(geo_value, time_value, value) %>%
     as_epi_df(as_of = as_of)
   max(nhsn_flu_tbl$issue)
   #> [1] "2026-01-25"
   range(nhsn_flu_edf$time_value)
   #> [1] "2020-08-02" "2026-01-18"
   nhsn_flu_edf %>%
     arx_forecaster("value", args_list = arx_args_list(adjust_latency = "none"))
   #> ══ A basic forecaster of type ARX Forecaster ═══════════════════════════════════
   #> 
   #> This forecaster was fit on 2026-02-10 12:54:30.
   #> 
   #> Training data was an <epi_df> with:
   #> • Geography: state,
   #> • Time type: week,
   #> • Using data up-to-date as of: 2026-01-21.
   #> • With the last data available on 2026-01-18
   #> 
   #> ── Predictions ─────────────────────────────────────────────────────────────────
   #> 
   #> A total of 54 predictions are available for
   #> • 54 unique geographic regions,
   #> • At forecast date: 2026-01-18,
   #> • For target date: 2026-01-25,
   #> 
   nhsn_flu_edf %>%
     {attr(., "metadata")$as_of <- as.Date("2026-01-18"); .} %>%
     arx_forecaster("value", args_list = arx_args_list(adjust_latency = "extend_ahead"))
   #> Error in `bake()` at recipes/R/recipe.R:794:5:
   #> ! There is more latency at bake time than there was at prep time. You
   #>   will need to fit a model with more latency to predict on this dataset.
   nhsn_flu_edf %>%
     {attr(., "metadata")$as_of <- as.Date("2026-01-18"); .} %>%
     arx_forecaster("value", args_list = arx_args_list(adjust_latency = "extend_lags"))
   #> Warning in bake(step, new_data = new_data): There is less latency at bake time than there was at prep time. This will still
   #> fit, but will discard the most recent data.
   #> ══ A basic forecaster of type ARX Forecaster ═══════════════════════════════════
   #> This forecaster was fit on 2026-02-10 12:54:31.
   #> 
   #> Training data was an <epi_df> with:
   #> • Geography: state,
   #> • Time type: week,
   #> • Using data up-to-date as of: 2026-01-18.
   #> • With the last data available on 2026-01-18
   #> 
   #> ── Predictions ─────────────────────────────────────────────────────────────────
   #> 
   #> A total of 54 predictions are available for
   #> • 54 unique geographic regions,
   #> • At forecast date: 2026-01-18,
   #> • For target date: 2026-01-25,
   #> 

   ^{Created on 2026-02-10 with reprex v2.1.1}
3. brookslogan commented on Feb 10, 2026

   

   brookslogan

   on Feb 10, 2026

   ContributorAuthor

   More actions

   Aside: I've also put count data into a model that shouldn't be run on count data here. But I hope that's unrelated.
4. docxology commented on Sep 16, 2026

   

   docxology

   on Sep 16, 2026

   More actions

   Upstream supplement draft — M5 → comment on #474

   Disposition: DOWNGRADED to supplement. #474 ("Make adjust_latency work or give nicer debug messages (on weekly data?)", open) reports extend_lags producing absurd lags (73, 80, 87) on weekly data and asks how. The mechanism below is, I believe, the root cause — or at least a major contributor. Post this as a diagnosis comment on #474.

   ---

   Likely root cause: latency is computed in days but applied in native units

   • get_latency() always returns days: as.integer(sign_shift * (as.Date(forecast_date) - shift_max_date)) (R/utils-latency.R:143 on HEAD 43b352f / main 7d8539b).
   • epi_shift_single() then adds that value in the data's native units: mutate(time_value = time_value + shift_val) (R/epi_shift.R:16), where + is yearweek/yearmonth/yearquarter arithmetic.

   For a yearmonth epi_df with as_of ~1 month after the last row, get_latency() computes ~31 (days); create_shift_grid() yields shift_val = lag + 31; epi_shift_single() shifts by 31 months. On weekly data the same confusion produces the off-lattice shift amounts #474 observes (multiples of 7 landing where weeks don't exist).

   The test suite defers exactly this case: tests/testthat/test-step_adjust_latency.R:374 contains an empty # test_that("epi_adjust_latency works for other time types", {}). Meanwhile check_interminable_latency() has explicit week/yearmonth/yearquarter thresholds (R/utils-latency.R:270-275), so these configurations are clearly contemplated as supported.

   Suggested fix

   Convert the latency to the data's native units before create_shift_grid() (time_type-aware period arithmetic, similar to what layer_add_target_date() does via coerce_time_type()), or error early for non-day time_type and document day-only support. Filling in the deferred test at test-step_adjust_latency.R:374 would settle which.

   Related

   #472 (the adjust_latency docs gap) and #409 (max-latency cap feature) touch the same machinery but neither covers the day-vs-native-unit mismatch.