Additive Exception to Repeating Date

I was planning to do this, but I'm handling all feature requests in the 6.2 queue, then backporting them.

The iCal specs allow for multiple recurrence rules.

If I understand correctly, what you want is to be able to do something like : Every Wednesday, but also Friday Oct 31. To do this you could have two recurrence rules, one for "Every Wednesday", a second one for "Once Friday Oct 31".

See :
http://www.kanzaki.com/docs/ical/rrule.html
http://www.kanzaki.com/docs/ical/recur.html

Now, I'm not sure how complicated it is to implement multiple recurrence and exception rules.

Implementing multiple recurrence rules would create a really messy UI. What I was thinking of was the normal way of doing recurrence rules, plus a way to list individual exception dates, plus a way to list individual additional dates. That should cover all but the most complex situations.

Marked #570216: Include Dates Without Recurring Pattern as duplicate of this issue.

Subscribe

The GUI for this could be really simple (I don't know about what coding has to be done) but just a simple set of radio buttons next to the exception date labeled Exclude and Include.

I had a little look into this - you're right, the GUI is easy enough to replicate. What is difficult is the fact that adding individual dates doesnt seem to be within the RRULE framework, but the ical specification does allow us to combine the results of RRULE and RDATE (individual repeating events). Is it ok to introduce RDATE so that the 'field_date_rrule' in the CCK date field looks like this.

RRULE:FREQ=WEEKLY;INTERVAL=1;UNTIL=20140131T050000Z;WKST=SU
RDATE:20100311T050000
EXDATE:20100218T000000

So, some questions:
1. If we introduced RDATE would it be recognised, or would we need to write functions to recognise it somewhere?
2. Is this an ok way to proceed? If so, I'll see about knocking up a patch.
3. One thing - 'Takes place every week, and also on Oct 18, 2010' sounds a bit odd. It would also be nice to suppress this text somehow in the following case: Where I am doing a site for athletic races around the world: some of them take place every week, some of them every month on an arbitrary date, and I'd like to use the same date field for both. So for the races that take place at arbitrary times every month, only the RDATE is specified, and the text doesnt show.

The jQuery plugin "FullCalendar" ( http://arshaw.com/fullcalendar/ ) could be a great UI for adding multiple date rules...
I believe this can be a lot of work, but will be a very good addition to the Date module.

---
Oussama Mubarak // Semiaddict

@semiaddict I agree that jquery calendar is fantastic - we are currently using the fullcalendar on our site with custom AJAX callbacks. The other interesting part to fullcalendar is that it has good API support for repeat events, but the GUI elements to alter the event are basically non-existent. A great example of this done well: http://fullcalendar.vinsol.com/ and the source: http://github.com/vinsol/fullcalendar_rails

I would love to do some work on this!

subscribe

Anyone else need this sort of thing? Any activity in terms of development? There's got to be a need for a more in depth scheduling information.

Any luck on this yet KarenS?

-R

Reading through all of this, a UI like the one mentioned in #11 look ideal for almost every drupal website I've ever built. As long as it had time based repeat functions (hourly, every minute, every second, etc.)

Here's a patch that implements RDATE to allow additional dates to be added to the set of repeating dates calculated by the RRULE. In UI terms it adds an additional dates form section beneath the "except" dates bit.

Please test!

Andy

Just noticed this was set to critical. It's not.

subscribe

If the EXCEPT field is changed to ADD/REMOVE then there would be no need to have an extra field on the form....

- if ADD/REMOVE date/time is the same as a repeating date/time, the repeat is removed (as it does now).
- if a ADD/REMOVE date/overlaps a repeating date/time, the new date/time replaces the repeat (a change of time)
- otherwise the new date/time is simply added (new date/time)

@dpatte I think that would be confusing to most users. You'd have to include your algorithm in the field description for anybody to make sense of what was required. And I think it's a bit too complicated.

The separate "Except" and "Additional" fields are quite clear and straightforward in what they do. They also mirror the way iCal works - i.e. separate EXDATE and RDATE fields. What's more it's easier to implement!

I can see that what you're proposing may allow for quicker more intuitive entry for some use cases (e.g. changing times), but not for most.

If someone would like to research how to incorporate the fullcalendar into Date module, that would be great! It might need to be a separate module and should be a separate issue.

I agree with the approach that chaps2 has taken to this patch, it feels like the logical way to do this. I'll try this out and see.

Note:
ablondeau HAS created a module to incorporate fullcalendar into Date module.
I think it works pretty well already, but does not work with repeating dates.

http://drupal.org/project/fullcalendar

This has been added to both the D6 and D7 versions. I would like to incorporate an 'add more' button to both the exceptions and the additions, but that is a different issue.

Thanks!

Thanks KarenS for looking this over. For those using your module, the 'add exception', and 'add more' would be wonderful to have running on our drupal sites.

#22 I don't understand the relevance of that to this issue. Can you explain how that modules is susposed to influence this issue (being additive exceptions for repeating dates?)

-R

I have excitedly tried the new add feature and I have noticed two issues.

1) Sometimes when you add a new date, it seems to add the date you required, but also add 'now' to the list. (effectively adding two items)

2) The add event portion is missing a time field. I thought we where going to be able to add any date/time to our list. "Runs every friday at 8, plus also this wednesday at 9".

I'll backup to yesterday's dev instead.

unfortunately, backing up to the previous dev doesnt work either, reports date_set_time not found.

The omission of the time field is by design. The exceptions and additions all use the same time as the original date. I'm not sure the code would work right if we had a few dates with different times.

The error needs examination, maybe someone can dig into that.

#26 - I haven't been able to replicate the error. Can you give any more information that might help - e.g. field/widget type, widget settings etc?

in #27, i overwrote yesterdays dev with the dev of Oct 26th. Now on editing, I get the following error.
Fatal error: Call to undefined function date_set_time() in /.../sites/all/modules/date/date_repeat/date_repeat_form.inc on line 248

I then tried overwriting with 2.6 and same error. I then deleted the complete date folder of my site and readding the dev of Oct 26th, and it still gets this error.

Im not sure if I should be doing an update.php in trying to restore.

As for part #1, of #26, I had a recurring node from Oct 26th to Nov 1st, all day. I tried to add New years eve (all day) but it also added the date and time of 'now' the time I was editing.

I think my proiority is to get back to stable 2.6 or preferably the dev before the add, but not having much luck.

The next thing I'll try is to delete the date folder off my server and see what happens if I upload 2.6 with no changes, do no update.php and see it it lets me edit nodes again.

I have 2.6 working again: deleted date of my webserver, upload 2.6, cleared cache, and its working. But then I overwrote with the Dev of oct 26th, cleared the cache, and it was broken again. "call to undefined function date_set_time(). (sorry to have dragged this issue into this thread - I'll drop it now and probably raise it as new issue instead)

So, for now I'll stick with 2.6, though I must say that removing the times as was done a few days ago gives the UNTIL & EXCEPT portions a much clearer UI. I just hope it will be possible to have times in the additive exceptions at some point - as this would allow people to have ANY date & time combinations for a single node using a single CCK field.

Re the error - line 271 of date_repeat/date_repeat.module reads:

unset($rdate['DATA']);

but should be:

unset($additions['DATA']);

I think the additions should have a time field. Without it we're missing out on one of the obvious uses of the additions field - i.e. to change time of event on certain days in the repetition. But you're right that the exceptions field should not have time. The code will work fine!

I have the latest dev, and my problem in #26 (1) is still there. I'll check the DB to see if the extra 'now' record is actually created and get back to you.

(Research:

indeed it did add an extra delta record with field_date_time_pattern_value = the time that I did the edit.
2010-10-28 15:41:25

Note that the field_date_time_pattern_rrule on all the deltas is now:
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20110202T095959Z;WKST=SU
EXDATE:20101030T000000,20101031T000000
RDATE:20110203T000000

)

Hi chaps, are you saying in that if i make that patch in #32 it should remove the bug im seeing in #33?

Also, is there a separate patch you can recommend to enable time fields on additions?

@dpatte - 1st question: yes. Regarding your 2nd question: No, there is no patch - hopefully Karen will reinstate times for additional dates - I can't see any reason not to. If you're desperate for working additional dates with times then try getting the latest stable build of the date project (6.x-2.6) and applying the patch in #16 which does not contain the error described in #32.

Thanks chaps. I can confirm that #32 seems to have fixed #33.

And I sure hope we can convince Karen of the advantages of putting the time fields back into the additions, that you had in the patch you submitted. It seems that it would allow any combination of extra datetimes to be added to a repeat field, making it very flexible for both patterned date/times, and non-patterned ones, al in a single cck field.

Good work, btw.

The problem with using times on the additional dates is that the original date can have both a 'from' and a 'to' value and if it does all the repeats use the same time period (i.e. 2-4 PM). In fact, the original date can span days (Nov 1 11PM to Nov2 2AM), and if it does the repeats (and now additions) again have the same time period.

If the additional date is going to have a time, it needs to have the same options to have a from and a to value as the original date uses. And that makes it really complex to do.

That's a totally separate issue because of that complexity. I added the option to have additional dates. If someone wants to figure out all the cruft around getting a from/to time in there you can work on it there. It will be messy so I'm not particularly crazy about adding it.

If there is a bug in the way this feature is working, that is a bug report, not a feature request.

And I committed the fix in #32. Thanks!

Thanks Karen for the explanation. I appreciate your feedback. I don't use to times, so I didnt notice this issue.

Unfortunately, I am still having issues with Date. I applied the fix in #32, and ended up after editing with something I didnt expect.

I had a node setup with repeating dates (every 2nd Saturday at 8:30 PM), and added Dec 31st. But it now shows Dec 31st as All Day.

Im not using end times.

Ah, yes. The additional date may not be picking up the right time. I need to look at that more closely. It should inherit the time from the original date. It may instead be picking up 23:59:59, which is what we feed to the UNTIL date.

If someone has time to try to come up with a patch that would be great. I will be pretty tied up for the rest of the week at least.

don't mean to be cynical, but too bad we can't specify the time ourselves :)

If you want it, write a patch. When you see how hard it is to do you will see why I am resisting.

I do appreciate all your work on this Karen, and if my php skills were more proficient, I'd certainly offer to contribute a patch. I was only teasing that it seemed funny that Chaps was adding times, which where removed, and now we are missing times which have to be put in.

But I do recognize that the real issues are likely far more complex than it sounds.

I will look into this...

Looking at the iCalendar spec, EXDATE can be DATE or DATETIME, whilst RDATE can be DATE, DATETIME or PERIOD (e.g. from and to datetimes). The way things were when I wrote the additional dates patch was probably good for most uses - i.e. the start time could be overridden in each additional date. That worked well where there was no "to" date. Where a "to" date was specified it looked like the event period was maintained for additional dates. e.g. from/to date is 10:00/14:00 then additional date time of 10:00 would be saved with a to date of 14:00 as well, but a different additional date time of say 11:30 would be saved with to date of 15:30 (i.e. +4 hours). That's not too bad - it probably covers 90% of typical use. The only additional dates scenario that is not supported is for a date that has a "to" date where the additional date has a different period - irrespective of whether time is allowed or not. So suppressing time input for additional dates doesn't provide any kind of fix - it just reduces functionality!

In summary - I accept that my patch was flawed in not supporting additional dates with different periods - but i don't accept that anything is achieved by suppressing time input!

Hopefully I'll find a bit of time in the next few days to add full and proper support for additional dates of type period...

I dont need different periods, since I am only using from times. There where issues early on in Date with items that spanned midnights (such as 10PM to 1AM - they reported these events 'all day'), so none of my events now have end times. Chaps, as long as dates don't report dates as all day, unless perhaps if they start at midnight, then I think your solution would work well for me. In the case where start times change, I think having the same duration as the original date would probably work for most people.

Additive exceptions was released with the latest stable release.

If chaps is still monitoring this list, what would be involved in putting times back into additive exceptions. The way adds are currently working they now appear as 'all day'. Thats seldom the case I need. If we could specify start times for additive exceptions using karens latest released version as a base, that would work very well for my needs, for both repeating dates, and additive date/times.

When I add a date with no ending time, the new date is listed as "all day", but if there is an ending time, the start time becomes 12:00am regardless of the time set in the from and to date section.

Anybody make any progress on this? The "Additional dates" field is basically unusable in about 99% of use-cases at the moment - it doesn't use the time of the original event, but it doesn't have fields to set its own time.

By the bye, I think this is a bug - it doesn't pick up the time from the original date, which is what I read the thread as saying it should.

it would be best for now if it allowed you to enter a time This way you could add any times, even those that are outside the default values. A while back somone had a patch that did this but we seem to have lost him.

@dpatte - If you mean me then I'm afraid I can't see what I can add without further comment from Karen - see my last comment #45.

hi chaps2 - yes, i meant you :)

You did a great job of adding additive exception with times to the previous released version, and it worked great for me since I don't use end-times at all. I could have a repeating date/time, plus any other start date/times all in one cck field. The perfect solution. It was terrific. But since Karen has since upgraded the released version, Im not sure how to merge your last changes into it again. See my comment #48.

I understand that Karen wants a total solution, but in the mean time, the changes you made previously did at least work for alot of people. With all due respect for Karen, the current implementation doesnt work at all for additive exceptions - since they all become 'all day'. At least your change worked for all people that didn't use end times.

My tests with various iCal files indicate that if you specify a starting RDATE in iCal date format it will default to the duration of the original meeting. All that's needed is to add 'month' and 'year' to the fields, and slightly alter the date_compute function to include the timezone. And the concatenation should be '/' instead of ','.

From the user standpoint It seems intuitive that the meeting would, absent a start time, be the same duration as the original - or that a from time would give you the same duration. And the iCal spec allows for that. So an additional "to" I don't think is really necessary.

I frequently need to put events on a calendar where the first and/or last day's hours are different (usually shorter) than the rest of the days, so I would really like both from and to times. As it is, I usually have to treat the odd houred days as separate events from the main body of the event; somewhat difficult to explain to the client.

chaps2, I second dpatte's comments, it's a shame that this functionality got removed for whatever reason, and barring a complete solution, I think at least for usability's sake we need something better than what's there now. If you already had some code to add a time to the "additional" field, would it be possible to roll something off dev to get us at least started?

I'm happy to take a stab also - indeed I have something half finished (just adding a From time) - but if something like that already exists that you've spent time on...? :)

subscribe

It would be very valuable to be able to inherit the time for the repeating dates.

Patch posted here: #1053158: Add time field to "Additional" repeat dates

Has this been committed, nfd?