Date support for {epidemics}

[pratikunterwegs]

This discussion comes from a query by @sbfnk as to what it would take for {epidemics} to be suitable for submitting output to scenario modelling hubs; an example of the submission requirements and guidelines can be found on the Midas Hub flu modelling repo.

{epidemics} currently has very basic support for time as it returns a 'time' column that is to be interpreted as 'days since start of epidemic', which might make it challenging to use the package for scenario modelling over a specific timeframe with defined start and end dates. This sort of functionality was needed when {epidemics} was used recently for this report.

This Gist shows a prototype of new functionality in the default model that improves how time is handled. This can be tried from the dev-epiweek branch.

• the time_end and increment arguments have been removed;
• time_end has been replaced by duration, which is expected to be the epidemic duration in days;
• increment is now set to a default of 1.0, which is expected to be 1 day;
• The start_date argument allows an optional start date to be passed by the user; defaulting to the current date.

Note that the example plot spans the year end causing the epiweek to reset.

This functionality could be extended to all models - it would be great to hear what could be added to serve related use cases.

[adamkucharski]

Thanks for sharing. Getting dates and timesteps is always a big time sink when working with models alongside data.

A few thoughts, building on experiences of interacting with various models and packages:

• Requiring date inputs can create some friction for quick exploratory analysis, unless very easy to input (e.g. as.Date("2020-01-01") etc.). But, of course, the alternative is to require wrangling in post-processing of outputs. I tend to prefer date for avoidance of doubt to 'epi week' (given different agencies may define this differently).
• Scenarios are often done on durations (i.e. risk over next 3 or 6 months), so that seems reasonable as default (user can easily derive this from an end date with 1 line of code anyway).
• It's unlikely data will be available on timescale of less than a day, so this seems sensible as default output, then user can always use incidence2 to reassemble if they need weekly etc.

[pratikunterwegs]

Thanks - I think there's definitely scope to make life easier for users:

1. The Date input is indeed as simple as as.Date("2020-01-01"), and defaults to the current date so users don't even need to pass it; the epiweek framing comes I think from the CDC-CFA/Midas Hub requirement on model outputs;
2. The duration argument could definitely be modified to accept interval objects such as from {lubridate}.