我正在构建一个需要支持重复事件的组日历应用程序，但我提出的处理这些事件的所有解决方案似乎都很简单。我可以限制一个人可以看多远的未来，然后一次性生成所有事件。或者，我可以将事件存储为重复的，并在日历上动态显示它们，但如果有人想更改事件的特定实例的细节，则必须将它们转换为正常事件。
我相信有更好的办法，但我还没找到。对重复发生的事件建模的最佳方法是什么?在这种方法中，您可以更改或删除特定事件实例的细节?
(我使用Ruby，但请不要让这限制了你的回答。如果有ruby特定的库或其他东西，那么最好知道。)
当前回答
我建议使用ruby的date库的功能和range模块的语义。循环事件实际上是一个时间，一个日期范围(开始和结束)，通常是一周中的某一天。使用日期和范围可以回答任何问题:
#!/usr/bin/ruby
require 'date'
start_date = Date.parse('2008-01-01')
end_date = Date.parse('2008-04-01')
wday = 5 # friday
(start_date..end_date).select{|d| d.wday == wday}.map{|d| d.to_s}.inspect
产生事件的所有日子，包括闰年!
# =>"[\"2008-01-04\", \"2008-01-11\", \"2008-01-18\", \"2008-01-25\", \"2008-02-01\", \"2008-02-08\", \"2008-02-15\", \"2008-02-22\", \"2008-02-29\", \"2008-03-07\", \"2008-03-14\", \"2008-03-21\", \"2008-03-28\"]"
其他回答
查看下面的文章，了解三个优秀的ruby日期/时间库。 对于递归规则和事件日历需要的其他东西，Ice_cube似乎是一个可靠的选择。 http://www.rubyinside.com/3-new-date-and-time-libraries-for-rubyists-3238.html
您可能想要查看iCalendar软件实现或标准本身(RFC 2445 RFC 5545)。 很快想到的是Mozilla项目http://www.mozilla.org/projects/calendar/，快速搜索也会显示http://icalendar.rubyforge.org/。
可以考虑其他选项，这取决于您将如何存储事件。您正在构建自己的数据库模式吗?使用基于icalendar的软件，等等?
您可以将事件存储为重复的，如果编辑了特定实例，则创建具有相同事件ID的新事件。然后，在查找事件时，搜索具有相同事件ID的所有事件以获得所有信息。我不确定您是否滚动了自己的事件库，或者您是否正在使用现有的事件库，因此可能无法实现。
I would use a 'link' concept for all future recurring events. They are dynamically displayed in the calendar and link back to a single reference object. When events have taken place the link is broken and the event becomes a standalone instance. If you attempt to edit a recurring event then prompt to change all future items (i.e. change single linked reference) or change just that instance (in which case convert this to a standalone instance and then make change). The latter cased is slightly problematic as you need to keep track in your recurring list of all future events that were converted to single instance. But, this is entirely do-able.
因此，在本质上，有两类事件-单个实例和重复事件。
我开发了多个基于日历的应用程序，还编写了一组支持递归的可重用JavaScript日历组件。我写了一篇关于如何设计递归式的概述这可能对一些人有帮助。虽然有一些建议是针对我所编写的库的，但所提供的绝大多数建议都适用于任何日历实现。
以下是一些要点:
Store recurrence using the iCal RRULE format -- that's one wheel you really don't want to reinvent Do NOT store individual recurring event instances as rows in your database! Always store a recurrence pattern. There are many ways to design your event/exception schema, but a basic starting point example is provided All date/time values should be stored in UTC and converted to local for display The end date stored for a recurring event should always be the end date of the recurrence range (or your platform's "max date" if recurring "forever") and the event duration should be stored separately. This is to ensure a sane way of querying for events later. Read the linked article for more details about this. Some discussion around generating event instances and recurrence editing strategies is included
这是一个非常复杂的话题，有很多很多有效的方法来实现它。我要说的是，我实际上已经成功地实现了几次递归，并且我会谨慎地从那些没有实际使用过递归的人那里获得建议。
