Cleanup deployment-start-time feature branch, add tests

[serinamarie]

Continuation of #7772

Notes

dateparser.parse has a default PREFER_DATES_FROM setting of current_period. This means that when parsing a date, it will go backwards in time if that's closer than a future time, e.g. if it is currently 5pm, then dateparser.parse("1pm") will retrieve a date from earlier today (in the past) because this 1pm is closer than tomorrow at 1pm.

By changing the PREFER_DATES_FROM setting to future like in this PR, when parsing a date, it will always go forward in time regardless of closeness, e.g. if it is currently 5pm, then dateparser.parse("1pm") will retrieve the next future instance of 1pm, meaning tomorrow at 1pm even though today at 1pm is closer in proximity.

We reasoned that most of the time, users want to run deployments at a future date, so we should consistently parse for a future date, rather than inconsistently provide a past date or future date based on proximity.

If needed someday, we could add a setting to enable other behavior.

Example

Checklist

• This pull request references any related issue by including "closes <link to issue>"
  • If no issue exists and your change is not a small fix, please create an issue first.
• This pull request includes tests or only affects documentation.
• This pull request includes a label categorizing the change e.g. fix, feature, enhancement

[zanieb]

Why do we need the higher version?

[serinamarie]

These tests were failing: https://github.com/PrefectHQ/prefect/actions/runs/3752658214/jobs/6375066682#step:12:236
I determined the cause to be: scrapinghub/dateparser#1045 and the solution was implemented here: scrapinghub/dateparser#1046.

[zanieb]

Since the above exits if both are set you can just do

if start_in: ... 
elif start_at: ...
else: ...

[serinamarie]

Do you mean else: being where start_in is None and start_as in None? Because there is some logic beneath that specific to start_in/start_at for assigning start_time_parsed, scheduled_start_time, and human_dt_diff.

[zanieb]

Yeah I think you can do else instead of elif start_in is None and start_at is None:

[peytonrunyan]

I'm curious too what this would look like without having a helper function for the raw parsing logic.

[zanieb]

I think the helper function is a bit harder to read than the initial implementation, especially since it does more than one thing (parses the date time and generates a formatted diff). I don't have strong feelings here though.

[zanieb]

(unresolving for visibility; does not mean it needs to be addressed)

[peytonrunyan]

A couple minor ux nits (not strong feelings) but otherwise lgtm!