Updated date range selection workflow

[clarkus]

Is your feature request related to a problem?

Selecting a date range in PostHog can be pretty tedious depending on what you're trying to accomplish. Select a starting date for a fixed time range requires three clicks / actions just to pick the first range parameter. Our list of preset rolling time ranges use days as the most common time unit, but research shows that users use a broader range of units.

Describe the solution you'd like

Prioritize selecting rolling / relative date ranges using a list of preset values. Reduce the number of options and provide a semi-custom rolling range via a numeric input and a time units. The core change here is to provide a semi-custom rolling time range option. These are always relative to the current date and are formatted as a numeric value and a time unit option. For example, the last [3] [days], the last [1] [quarter], the last [18] [weeks]. A custom option would reduce the need for specific presets. We could also increase user confidence if we translated relative ranges to actual time frames using tooltips.

Relative dates are represented as relative ranges in the summary state for the picker. Likewise, fixed / absolute range are more specific and show the actual range selected.

Separate selecting a fixed / absolute range and provide reasonable defaults to reduce the number of actions it takes to submit a value. When selecting a custom fixed range, ditch the start and end date inputs and instead directly show the calendar immediately. A user would just need to select a start date to have a valid time range if the end date defaults to the current date.

Changes to consider based on the research @marcushyett-ph did for https://github.com/PostHog/product-internal/pull/305

1. Change the default rolling time range to 30 days for insights
2. Automatically adjust time grouping units to the range selected. For example if you select the last 24 hours, today, yesterday, it doesn't make sense to group by any unit larger than a day. Hours would be the most approachable unit for this scenario.
3. When selecting a fixed time range, disallow selection beyond the current date. It doesn't make sense to look at future dates in this scenario. We don't have data for the future as we don't do predictions. Our default end date for a custom time range should be the current date.
4. When selecting fixed ranges, reduce the number of clicks / actions it takes to get to the calendar interface. Right now this takes three clicks just to pick a starting date. We also make users select an end date when we could have a reasonable default of the current date here.
5. Add a quarterly option to the relative range picker
6. Make it more obvious when a fixed range is applied to an insight.
7. Consider expanding our preferences / project settings for time. For example, starting the week on Monday instead of Sunday, time value formatting (12 versus 24 hour clocks), timezones, etc.

Additional context

• https://github.com/PostHog/product-internal/pull/305

• Return to custom date range panel when adjusting date range after already using custom date range =] #9664

• Design: Changes to the date selector for queries, for ease of use and physics  #9453

• Improve the date picker in Insights #9027

• Allow filtering with date/time properties #6619

• DateTime property filters should allow relative dates #8640

• Request: Time-editable Dashboards for Collaboration #8460

• Insights date filtering/interval logic is confusing #8059

• Large date ranges are not handled well with small intervals #7625

• Figma - https://www.figma.com/file/NHPA2hVWwaKp4eTGWdigs9/?node-id=1768%3A6935

Thank you for your feature request – we love each and every one!

[clarkus]

Related but somewhat separate are time ranges for dashboards. Dashboards can override an insight's time range temporarily. The same considerations for picking a time range could apply to the dashboards feature.

[joethreepwood]

This looks like it addresses my feedback perfectly - thanks Chris!

[marcushyett-ph]

This is super-solid, thanks @clarkus!

[kappa90]

Incorrectly closed after #10462, which is meant to run as an experiment