我有一个用于跟踪经常性截止日期的系统，该系统基于Google Calendar API构建。事件用于对任务进行建模，这些任务具有存储在sharedExtendedProperties中的其他状态：例如，帐号，任务分配给的人，任务类别，特定于域的状态等。状态因实例而异。
用户设置任务时，他们不知道会重复多少个月。因此，最初在重复规则中没有设置UNTIL日期。最终，当他们知道系列中的最后任务时，他们想设置UNTIL日期。他们还可以在中途更改重复规则：例如，将到期日期从每个月的第二个星期二更改为每个月的第11个日期。
在任何一种情况下，用于执行此操作的机制都是修改现有的重复序列以设置UNTIL日期（在第二种情况下，还要创建一个从该日期开始的新序列）。
仅当现有重复序列实例中的重复规则没有例外时，此方法才能正常工作。如果只有一个originalStartTime异常，比如说一个实例从第二个星期二移回了第二天，那么当重复规则更改时，看来所有实例都被清除并重新从“主” recurringEventId记录的初始状态创建。这意味着他们失去了自最初创建事件系列以来在所有实例上进行的状态更改。
我可以做类似保存所有状态的操作，然后对重复进行更改，然后在更改后返回并在originalStartTime上逐一匹配每个实例（如果且仅当存在任何例外）-但这很麻烦而且很耗时。
有没有更好的方法来解决这个问题？