Duration (and end_time) assigned to Rules instead of Schedule

[Chosko]

Thanks for this gem, it's super useful and I like everything.

There's a feature I would like to implement though, but before starting I'd ask you what you think about it.

I suppose this gem is built with the convintion that the duration (or end_time) should be related to the schedule, but I think it's better to assign duration to the Rules. I explain why.

I'm creating a Rails booking engine, that should allow developers to implement a booking system for various use cases (hotels, apartments, shows, meeting rooms etc...). Let's take the MeetingRoom case.
I would create an IceCube::Schedule attribute into the MeetingRoom model, that represents the availability of the MeetingRoom. Let's say this MeetingRoom is available on mondays and tuesdays from 8AM to 10AM and from 2PM to 6PM.

the 8AM-10AM interval has a duration of 2 hours, while the 2PM to 6PM has a duration of 4 hours. Having the duration related to Rules would allow for keeping the whole availability of the MeetingRoom inside the same Schedule. This would be great for making occurrence queries once, instead of having a number schedules I should cycle everytime.

I hope I explained the problem. I'm really interested in this gem, and it would be great to include it in my engine, but the single schedule thing is a costraint I need.

[Chosko]

To avoid breaking compatibility, we may treat the duration inside the Schedule as the default duration. Then, if a rule specifies a duration, that duration overrides the Schedule's one.

[pocman]

I also have the same need.
One workaround could be to define your duration as the smallest availability interval (here, 2 hours).

[avit]

I can definitely see the need for it. I'm just not sure how it fits with the iCalendar spec (RFC 5545) for compatibility with .ics format, maybe there's something in there, or in one of the "updated by" specs on top of it.

I'm open to it if we can roundtrip iCal export...

See #131 for my original thoughts on this too... that approach would cover more than just duration differences.

[BGuimberteau]

👍

[MGPalmer]

👍
Similar use case here! I would add a requirement to also move the start time and the exceptions into the Rule - basically everything, making the Schedule only a container ;) That would allow full interwoven rhythms to be modeled in one Schedule object.

To illustrate, our use case is a bus schedule. There's a base schedule (every day 08:00 since start of year), then additional buses in the afternoon on the weekend (but only in the winter season), and on top occasional single buses for special occasions like christmas.

[vl3]

👍
Has this been already implemented? It would work great for booking systems. I don't know how the iCal protocol works but perhaps an intermediate solution could be just to warn the user that if it's using this feature, iCal compatibility will break.