Consider "time diff" helpers

[brookslogan]

Context

• difftimes can have weird interactions with conversions and arithmetic if not carefully accounting for which functions consider their units, etc. They also don't work for yearmons. They are also slow for some operations like min().
• Lack of good time-point/interval-differencing functions seemed to be an issue influencing refactor(epi_slide, epix_slide): time types refactor #472. Potentially could be / could have been useful in Fix guess_period on datetimes, make it more precise + generic #484, Add complete.epi_df method so grouped completions don't drop epi_df… #488, revision analysis first draft #492.

Proposal

Consider implementing these helpers:

• unit_time_diff(time_type): takes a time_type, outputs an object that, added to a time_value of kind time_type, will output the next possible time_value, and which is an acceptable before argument.
  • For "daily": either 1 or as.difftime(1, units = "days")
  • For "weekly": as.difftime(1, units = "weeks")
  • For yearmon: 1
  • etc.
  • This could be mostly S3 except for "daily" vs. "weekly" Dates.
  • (Maybe tack on a "time_diff" class so we "know" that we generated these results.)
• n_periods_to_time_diff(x, time_type): outputs x * unit_time_diff(time_type) (note recycling rules should mean this works on length != 1 vectors)
• time_diff_to_n_periods(x, time_type): reverse operation, but allowing for both the numeric and difftime as inputs for "daily", whereas in n_period_to_time_diff we'd just choose to output one or the other. (Or maybe be strict and have an as_time_diff convert to the strict format.)
• {is,assert}_time_diff(x, time_type): validates whether x looks like it's an appropriate time difference. Like validate_slide_window_arg but maybe not allowing Inf
• [time_diff(time_values, time_type) (like diff()), time_sub(time_values1, time_values2, time_type) (like -)? with time_sub maybe catching mismatched wdays for "weekly" --- again, this is almost but not quite just S3 due to "weekly" Dates, and not sure about tsibble/clock classes]

Use cases:

• before, after validation in non-Inf case
• maybe making working with guess_period, complete, etc. easier
• avoiding slow difftime operations
• [potentially supersede next_after]
• [potentially help clarify what type lag should be when we calculate it]

Discussion

@dshemetov @dsweber2 do you see these simplifying life at all?