Challenges with the `schedule` table for organizations in the USA

Technical
13

Hi folks,

I’ve mocked up some sample data of how a service could look with some changes to the schedules object, that Skyler and I have been discussing:

Broadly, the changes can be summarised as the following:

  • deprecate service.schedules, but replace it with two fields: service.opening_hours and service.events. Each of these is a separate array of schedule objects, with different semantics (one is for the regular hours or opening hours, one is for events)
  • add in a schedule.group field which allows systems/publishers to group individual schedule objects. For example you might have separate weekend and weekday hours, which are in turn different across holiday periods. This allows you to label each schedule as belonging to a group. Systems can use them to determine which schedules would go together.
  • add in a schedule.shortcode field which draws from a codelist (enum) and acts as shorthand for particular recurrence rules e.g. 24-7 or 24-hours.

Keen to hear thoughts. I’m definitely not wedded to any particular field names etc. so feel free to suggest alternatives e.g. if service.regular_hours is better than service.opening_hours etc.

I think we’ll add this as an agenda item to the commmitte meeting, so there’ll also be an opporunity to feed back there.

Skyler and I are intending to work through this some more with the goal of putting a proposal in for a MINOR upgrade at some point in the near future.

Standing Technical Meetups
Standing Technical Meetups