Overlapping Partition Timestamps In Tag Historian When Changing Partition Length

Hey guys, I'm looking at an issue here after changing our tag historian database partition units from one month to one week. Before changing this configuration, each partition had a single entry in the sqlth_partitions table, now there are several entries per table, and it seems that for a few months there were overlapping partition tables being created. Tables were being created for the month, and for the week timeframes, and there is a mix of data in both sets. Because of this mix up, there are two missing weeks when querying tag history until the issue corrected itself.

Does anyone know, if I just copy all data in the month table into the correct respective week table, and then clean up the partition timestamps, if everything should work correctly? Are there any other dependencies for table partitions that I might be missing here?
Here is a table of all my sqlth_partition entries where you can see the prescribed start/end times and the actual timestamp range of data that the real partition tables hold:

I'm assuming this is some timing/cron bug where the rule to create the next table didn't get cleared out in time for the new partition schedule to take over? Not super sure how it works in the backend.

(Also a little annoying how the naming scheme for the different partition length units isn't the same)

Here is the same table with the UNIX timestamp converted to datetime for easier viewing: