Skip to content

Date processing mismatch #291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dajmcdon opened this issue Feb 3, 2024 · 1 comment · Fixed by #297
Closed

Date processing mismatch #291

dajmcdon opened this issue Feb 3, 2024 · 1 comment · Fixed by #297

Comments

@dajmcdon
Copy link
Contributor

dajmcdon commented Feb 3, 2024

  1. The canned forecasters expect forecast_date and target_date to be Date objects.
  2. step_epi_ahead() and step_epi_lag() require lag/ahead to be integers.

This generally works OK unless you're doing annual forecasts (probably also monthly). Then these clash (because of leap years or strange numbers of days).

Suggested fix:

  1. lead / lag processing should handle things like "1 day" or "1 year". They should operate using date arithmetic on the level of the epi_df time_type. So if time type is year, ahead = 1 should automatically convert to "1 year".

This is possibly related to #290 .

Likely requires importing {lubridate} and then downstream licensing issues. See tidyverse/lubridate#968

@dajmcdon
Copy link
Contributor Author

dajmcdon commented Feb 3, 2024

This is currently blocking #115

dajmcdon added a commit that referenced this issue Feb 3, 2024
@dajmcdon dajmcdon linked a pull request Mar 18, 2024 that will close this issue
4 tasks
@dajmcdon dajmcdon mentioned this issue Mar 18, 2024
4 tasks
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 a pull request may close this issue.

1 participant