Possible issue on dates lining up

[athowes]

In @cmilando's code he does work to change the dates using INCUBATION_SHIFT and REPORTINGDELAY_SHIFT. Do we need to be doing that here to make the dates line up for the different packages?

[annecori]

Agree - in addition may want to consider what is the best time point to use for comparison, e.g. EpiEstim provides an estimate over a period from start_date to end_date so the best comparison point may be to use the midpoint of this when comparing to methods such as EpiNow2 which (I think) provide a single point estimate

[annecori]

An issue to consider is for methods like EpiNow2 the shifting above should be made to match the incubation period etc that were used as inputs to the EpiNow2 call, whilst in EpiEstim for example this will need to be an external input

[annecori]

so to recap: summary of the issues are:

1. how to properly align dates across the 4 packages - currently all are ok except I think EpiEstim should be using the midpoint between t_start and t_end instead of t_end
2. for the packages which do not account for delays in reporting and incubation, we should have an easy way to shift the estimates in time by the appropriate amount for comparability with packages such as EpiNow2 which do account for these and therefore provide Rt estimates by date of infection. This means adding options for EpiLPS, EpiNow2 and RtEstim to shift all estimates by 1 mean delay (mean incub + mean delay between symptoms and reporting) - this should be an external input though as not considered as input of those packages