I'm a little worried about these getting unwieldy... do we just expect most of the time-based partition params to be constructed by one of the schedule decorators?

@prha would having a separate PartitionOffset namedtuple and PartitionExecutionTime namedtuple help with the unwieldiness? Kind of a cosmetic difference but a lot of the explosion of fields seems to stem from those two structures having a lot of optiosn

I'm mostly concerned about the API docs. If we feel like a user could look at the docs site and figure out what they should use without getting overwhelmed, I think this is fine. I was thinking that it might be easier to describe the containing offset parameter and the containing execution time parameter rather than each individual value, but agree that it's mostly cosmetic.

I was going to suggest writing out the exploded api docs out in this diff, but then realized this isn't even exported.

If we don't expect users to populate these directly, I don't care even a little about the unwieldiness.

I'm actually a little unclear on whether users create these directly - these are intended to be kind of like serializable versions of schedule_partition_range / date_partition_range right rex? What do you expect the way for a user is to create a time-based partition set (and a schedule based on a time-based partition set) once all is said and done?

My current thinking is that TimeBasedPartitionParams will be firstly be used by the schedule decorators. It's basically a serialized cron schedule, so any partition set that can be expressed through a cron schedule can be expressed through this class.

The schedule decorators thread these partition params through to the current PartitionSetDefinition in a partition_params field, as a replacement for the user specified partition_fn. In the future, we'll just expose docs on how set partition_params and then deprecate partition_fn fully (as its behavior is fully encapsulated by Static/TimeBased/Dynamic partition params).