检测重叠日期重复规则
我正在使用一个看起来像 Google 日历的应用程序，但有一个主要区别：事件不应与其他事件有交叉。这意味着没有两个事件可以共享相同的时间，即使是分钟粒度。这对于仅存储会议的日历特别有用，因为不可能同时参加两个会议。
就像 Google 日历一样，可以使用重复规则（例如，每个周五和周日上午 10 点到下午 13 点）创建事件。所以我想仅使用 rrules （python-dateutil 模块）来检测重叠事件，无需创建 N 个日期时间对象并检查每个对象的交集。
是否可以仅使用 rrules 来检测重叠日期？另一个库中是否已经实现了类似的功能？
I'm working in a application that looks like Google Calendar, but with one main difference: events shouldn't have intersections with other events. This means that no two events may share common time, even in minutes granularity. This is specially useful for a calendar that only store meetings, since it is impossible to be at the same time in two meetings.
Just like Google Calendar, events may be created by using recurrence rules (every friday and sunday from 10 AM to 13 PM, for example). So I would like to detect overlapping events by only using rrules (of python-dateutil module), without needing to create N datetime objects and checking for intersection against each one.
Is it possible to detect overlapping dates by only using rrules? Is there anything similar already implemented in another library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，我不认为可以分析一个规则来查看它是否可以在不创建日期时间对象的情况下与另一个规则相交。
本质上，您是在不运行算法的情况下询问算法的输出，我认为这是不可计算的。
然而，对于某些类型的规则是可能的 - 例如，每周四的规则不能与每周二的规则相交。有问题的是一个月中的日子和一年中的日子与一周中的日子相交，以及从不相交的频率。
最好的选择是制定可分析检查的规则，然后为其他人生成明年左右的数据并手动进行比较。
该算法可以快速运行，因为您可以在添加每个规则时缓存现有的占用时间。
No, I don't believe it's possible to analyse a rrule to see if it can intersect another one without creating the datetime objects.
Essentially you're asking for the output of an algorithm without running the algorithm, and I think that's non-computable.
However, for certain types of rrule it is possible - e.g. a rrule of every Thursday can't intersect a rrule for every Tuesday. The problematical ones are days of the month and days of the year intersecting with days of week, and frequencies that never intersect.
The best bet would be to do the rules that are analytically checkable analytically, then for others generate the next year or so's data and compare manually.
The algorithm can run fast, since you can cache the existing occupied times as you add each rule.