Address recurring regulations

[SarinaAtkinson-NOAA]

Now that #10 is done, we can use the test cases to compare to as we make changes to the code.

[AdyanRios-NOAA]

I will try to think about this more ahead of next Friday. To build up to this, I think I will just explore the working papers for a handful of known clusters with recurring reg types, that were already explored in depth in the working papers.

Thinking more about recurring regulations, the topic of multi-reg also comes to mind (regulations that co-exist and do not overwrite). That might be a good next issue or discussion to create. I wonder if this is already part of the skip-to-an-earlier-reg logic when flagged, but I don't recall.

[SarinaAtkinson-NOAA]

What do we want to do about recurring regulations. Below is showing the automated recurring closure table for Gulf red snapper (cluster 306)

And this is the working paper table:

They are not far off and in this first stage of processing, I do not think we need to expand to every month within the timeframe for monthly recurring closures.

[SarinaAtkinson-NOAA]

The code for expanding a recurring closure to the actual months/days that are closed is something we will need to address AFTER we give this code to Yanet. This step will be a part of the daily analysis-ready dataset which will actually be used for analyses. The printed analysis ready tables are intended to show the start and end dates for the FRs comprehensively between the time series. It is not meant to show the expanded dates.

Start and end dates for this example above for monthly recurring closures is working ok, there is overlap in the dates BECAUSE the start and end times are in the middle of the day.

[SarinaAtkinson-NOAA]

For this first phase of automation, recurring closures are ok.