When filling out a birth date it would make sense to be able to keep the 'until' field empty. Currently, when leaving this field empty, the following error is displayed: "The UNTIL value is required for repeating dates."

Comments

KarenS’s picture

I intend to do that in the next phase of development. It adds a lot of complication to the processing since I can't actually store values in the field in that case (since they go on to infinity) and I'll have to have a different way of processing those dates.

appel’s picture

Thanks for your reply KarenS, I greatly appreciate your work on this (and other) module(s).
Since infinity isn't really necessary, how about letting the module fill out a faux default value of, say, two hundred years in the future, in case the field is left empty by the user?

KarenS’s picture

Because if you don't want to use infinity, you have to make a decision what you will use, so you are setting an end date. If I don't have you set an end date, how can I know what is a safe one to use? And if I used, say, 200 years in the future, I could be creating thousands of multiple value entries in the table to fill out all the possible values for those 200 years.

We need a completely different system for that situation so we don't create nodes with hundreds of multiple value fields. I have some plans for how I will do that, but will be a non-trivial change that I can't do right now. And in the meantime you can get the same effect yourself by setting an 'Until' date somewhere far enough in the future that your dates will behave the way you want them to.

joachim’s picture

Subscribing.

KarenS’s picture

Version:5.x-2.0-rc» 6.x-2.x-dev

Actually, let's bump the version. This would be fixed in the latest code and then (hopefully) backported.

arlinsandbulte’s picture

Version:6.x-2.x-dev» 7.x-1.x-dev

Pushing feature request to HEAD

+1 for this feature, BTW.
I know it might change a lot of stuff. But it would be useful in a lot of ways!!!!!

bounsy’s picture

Version:7.x-1.x-dev» 6.x-2.x-dev

I'm also hopeful of getting this feature in 6.x.

OnlineWD™’s picture

Any news on this, seems there is no possibility to have reoccurrng events such as birthdays, anniversaries, special dates etc etc.

I can see the problem with infinity. The problem might be having to include a year. But perhaps you could only select everything except year for dates marked as reoccurring, insert in another table and check the calendar view for a month/day match, if true select/add node to view. The mark (check box) would mean date repeat would not have to be used therefore neither until, could disable repeat and until options if reoccurring check box ticked. Would also need options for occuring every year or month or day.

It is almost exactly like current repeat except until becomes indefinitely.

Jackinloadup’s picture

subscribing

arlinsandbulte’s picture

Component:Code» Date Repeat API

Note: marked #406376: Ability to have date repeat with no end date as a duplicate of this issue.

pauldawg’s picture

I am very interested in this as well. It seems that to truly support an "endless" approach you would need to allow the Date module to hook into the call made asking what the dates were and then reply as necessary given the context. In [406376] I mentioned that a default limit would need to exist to enable the "unlimited" value in the number of values to display when customizing the display of the repeat rule, but as is pointed out in this thread this is not the whole story. In order to support views integration and other basic querying capabilities, there would need to be some way of responding to the query in the appropriate context.

For example, if a basic view lists nodes with Data CCK fields and then lists the value of the To and From dates, how does it know the right context to respond to the query? To demonstrate this, think about a Calendar view; when you click on the instance of a repeating event, the display of that instance just shows you the basic information about that node, including the entire repeat schedule. So if I have a monthly event starting in January, and I go to the Calendar and display December, find the event and click on it, it shows me only the entire context of the repeating schedule, not where the current instance falls within the schedule. It would be nice if there were a context to determine the current display of that field. It's probably a fundamental rethinking of things but this is information that would be helpful to know as a user and as a designer.

This example might seem unrelated at first, since this is a limitation even with the existing system. However, therein lies the relevance. It seems that addressing this problem would lead to addressing the inability to have infinite recurrence. Since addressing this limitation would require modifying the logic so as to respond to date iteration in a particular context of a date, this would mean that that context could simply ask the repeating date to display its relevance to a given date range as necessary for that context. So if my monthly event needs to display itself respective to July of the year 5000, this wouldn't be any more difficult to do than any other year and would be a matter of simple math. It would not require creation of a predetermined list of recurrences.

Hopefully this makes sense and is helpful. Disclaimer: I have been with Drupal for 2 years but am only just beginning to get myself familiar with the Drupal core and the Date module.

pauldawg’s picture

This feature would be very useful for several reasons: Creating predetermined lists of Holidays to put on a calendar, birthdays (we don't want people to feel cursed if we put an arbitrary end-date on their lives), and just general repeating events that do not have a known end date.

One current problem with the limitation, distinct from the observable behavior of the actual repeat rule, is that there is no way to indicate that there is an intention to have an infinite recurrence, as the field itself is required. If instead of requiring the field be filled out we were able to leave it blank and then provide a configurable global module setting for the number of recurrences to calculate for future repetitions, this would be of value. One of the main reasons this would be useful is that the "until" phrase would thus be eliminated from the repeat rule display, signifying that the event is infinitely recurring despite the lack of ability to display events after a certain point.

For possible settings for the recurrence I would consider the following:

  1. Allow the administrator to set global display defaults.
  2. Allow content creators to use the "Default" setting or override for a particular node (as part of the Advanced field group)
  3. Allow the ability to specify either a fixed number of recurrences, or the end-date of the recurrences, or a relative end such as "now +10 years" in the aforementioned settings

These settings would be used to determine the "end date" as necessary for both display of the repeat rule when no limit is set, as well as for basic data calculation such as views integration. A benefit of this approach is that functionally the only limitation of this is the display of the data; the underlying schedule information is maintained for forward compatibility. At a later date when a truer infinite repeat capability were added with the ability to support context-based queries, we could simply remove the display settings widget and the related fields, and the existing infinitely recurring dates would contain the information necessary to display with infinite recurrence.

What do you all think of this approach?

pauldawg’s picture

Another place where the settings could be useful would be in the Views integration -- actually this is probably more important than allowing it to be available for content creators.

mattyoung’s picture

.

davidneedham’s picture

Any word on this yet? Will it be available in D7 then backported to D6?

mgifford’s picture

+1 for this feature.

YK85’s picture

subscribing

khan2ims’s picture

+1000

akolahi’s picture

I agree this feature would add great value to the module. I have found through the years that there have been many circumstances where it doesn't make sense to have an end date.

jeff.k’s picture

+1

chaps2’s picture

Having stumbled upon this issue I think the patch here - #397902: Support for simplified date field with repeat options widget - may be useful to some of you. It permits simple entry of repeating dates - e.g. birthdays without having to enter an UNTIL date.

vegantriathlete’s picture

RE: Comment #8

First of all, let me say that KarenS rocks!

@OnlineWD

It is possible to create a recurring date. The request here deals with making the until date optional.

I must admit that I had to do quite a bit of searching to figure out how to make the recurring date work. It took me a while to come across the documentation on this.

Here are the basics. In addition to enabling the date module, you will need to enable the Date Repeat API module. Then when you are configuring the field in CCK, make sure to select one of the widget options that includes the repeat functionality.

vegantriathlete’s picture

Title:Make 'until' field optional» Setting the until date "far enough" into the future

RE: (Comments #2 and #3) Setting the until date "far enough" in the future.

When you configure the field in CCK, change the Years back and forward from (the default of) -3:+3 to be something like -3:+20.

vegantriathlete’s picture

Ooops! Sorry for changing the issue title. I thought I was changing the comment title. I've changed it back.

mattyoung’s picture

Title:Setting the until date "far enough" into the future» Make 'until' field optional

There is a performance problem with setting the until date too far in the future because that will result in a huge number of entries in the database. Then all your queries will take forever. Your views will be very very slow.

KarenS’s picture

The fundamental problem is there is no way to use date with views unless the date is stored in the database (i.e. you can't compute a date on the fly in response to 'context' or anything else). If we store a date in the database we have to store *every* date in the database. And how many are there if you don't select an 'until' value? There are an infinite number of dates.

Something that repeats yearly is reasonable, but even that has to have at least an implied 'until' date if you are creating entries in the database. So the best you can do is have the admin identify what the implied 'until' date is, and that has to be adjusted for every possible type of entry. For instance, it would be fine to have an 'until' date of 1/1/2020 if you are repeating something annually (there would be 10 entries), but it would not be at all good if you tried to apply that to something that repeats twice a week (over 1,000 entries).

Because of the difficulty of making *any* assumptions about until date, I just ask you to supply it. You can then supply an 'until' date that makes sense for the date you have created.

entrigan’s picture

What if instead of relying on until dates, the date repeat had a "Number of stored instances" option which specified how many future instances to store in the db.

I am not 100% sure how to best design this system to be performant but one option is to have a cron task update the stored instances. Alternatively this could be handled with rules scheduling or even triggered by things like node edit or node view.

Ideally I think the form would read something like


[n] Number of recurrences (integer field or select list)
[0/1] Should this date recur indefinitely? (checkbox)
mr1’s picture

+1 And thanks.. You guys rock!

baff’s picture

subscribe

geerlingguy’s picture

This is something I'm actually working on, and might have to implement in a different way entirely than the date module. I have certain events (for instance, 'worship times' for a church) that repeat indefinitely, and shouldn't have an end date attached... nor should every instance of the date be stored in the database. That's a separate issue, though, than the main issue:

If you set the 'until' field to optional, and try to save the date or render a view with the repeating date in it (without a limit to the number of events displayed), PHP typically times out (that's the problem we're having over in #756134: Repeating events with too many occurences timeout; events without an end date (as valid in iCal) loop for ever / timeout).

It's a complex issue, to say the least, but I think that, to implement a proper fix, a new functionality needs to be introduced that simply stores the repeat rule and renders events on-the-fly instead of storing the repeats in the database (and showing them on the node page as a long list). Whether or not that gets done anytime soon, I don't know... but that's the only possible solution that I think would work for multiple use cases and allow this issue to be properly resolved.

This kind of functionality could be used for the following use-cases (all of which I've implemented haphazardly at various times), and negate the need for some Drupal modules that are currently annoying to have to use at certain times:

  • Birthdays (could negate the need for the Birthdays module).
  • Church service times
  • Office hours (could negate the need for the Office Hours module).

For my own internal tracking: Timefield module for CCK... or use Date repeating API.

KarenS’s picture

If you render events on the fly, you cannot use views. Views can only find events that exist in the database.

geerlingguy’s picture

That is a problem, of course, but would there be any way to modify either the views query or the results to allow a custom callback to be run for a certain date range? I know this is something I've looked into (albeit briefly) for FullCalendar... but not necessarily in the same way #971034: Add Option To Load Events Via Ajax.

Repeating events are a pain. (And dates are a pain).

arlinsandbulte’s picture

Crell (Larry Garfield) & mfer (Matt Farina), at Palantir.net worked on a solution for much of this and released the iCal module.
Here is a blog post detailing their efforts and the features that the iCal module adds to the Date & Calendar modules: http://www.palantir.net/blog/dating-complicated

In essence, I think the iCal module handles repeats by creating a node for each repeated instance form a master node. For long-term or never-ending repeats, it only creates a certain number of nodes so far out into the future, and then periodically adds more.

However, despite Crell & mfer being a couple of Drupal rockstars, the iCal module seems a bit half-baked to me. My efforts have not been successful at making it work on my test environments. The iCal module has a TON of dependencies and configuration details.

I think it would be GREAT if we could push the iCal module forward, or at least learn from it to improve on the Date & Calendar modules.

geerlingguy’s picture

However, despite Crell & mfer being a couple of Drupal rockstars, the iCal module seems a bit half-baked to me. My efforts have not been successful at making it work on my test environments. The iCal module has a TON of dependencies and configuration details.

Yeah, seems to be the same for me... I don't know if it's worth working on the iCal module much, especially as I don't see that effort as being quite as sustainable as having an 'infinite-repeat' event able to be used :(

mcaden’s picture

+1 on needing this.

I see the views problem and can understand that. The idea of having a number of instances in the future stored and having cron make sure there are always X number of future instances of that event is about the only way to handle it.

z-buffer’s picture

subscribing

chaps2’s picture

@appel - you need the catchily titled Repeating Date Presets! OK, it's not the perfect solution to the endless dates problem, but for birthdays, i.e. annual events, you can safely set the preset repeat rule to end 20 or 30 years hence. If you and/or your site are still around then you can update the rules...

A demo of birthday entry is here: http://drpdemo.locologic.co.uk/node/11/edit - log in with demo/demo. I intentionally left the year off the widgets for these fields as I don't want to create repeats for the last 50 years. If I need the year I'd ask for it separately.

dennys’s picture

+1 on needing this.

this function is useful, hope we can have it, thanks.

webadpro’s picture

Any updates on this feature?

klonos’s picture

...subscribing.

baff’s picture

subscribe

fultonchain’s picture

subscribing

Swift Arrow’s picture

Version:6.x-2.x-dev» 7.x-2.x-dev

Hi! I also need this feature! Here's a way it could work with cron:

@KarenS, what if you made an option "date repeats forever" checkbox, and then stored, say, +2 years (or provide a global variable) in the database, and hooked into cron to every so often change the dates?

You could make the frequency of the cronjob depend on the frequency of repeating, for eg: yearly, then run the cron date updates every 12 months, or weekly, then run the cron date updates every week.

Cron could then run through the nodes with the "infinite repeat" option, and keep pushing the dates up as needed.

Clean and simple, IMHO. Unfortunately, I'm not a PHP developer, I just build sites with Drupal, so I don't know what the code would look like.

Hope to see this update soon!!!

P.S. you're totally awesome for making this in the first place!

Swift Arrow’s picture

Title:Make 'until' field optional» Make 'until' field optional using cron

Just thought I'd change the title to grab some attention! Seeing as it's been 4 years... :)

Swift Arrow’s picture

I recently learned of the job scheduler module; perhaps that could be used to implement this?

Swift Arrow’s picture

Title:Make 'until' field optional using cron» Make 'until' field optional

bump, and change title since it could use cron or job scheduler or something else.

webankit’s picture

Can't we add until on the field setting and hide this setting on the content editing page
Also can we hide the exception setting

Niremizov’s picture

Regarding Views, we could make some plugin for date field, that would force Views to understand RRULE and to generate future instances of recurring event?
@KarenS - Could you tell us more about your plans how you are going to deal with this problem? Thank you.

Bobík’s picture

akolahi’s picture

Would it not be possible to use cron to compare all the 'no end date' values to the current date? If it falls within a certain time period (user defined) it will automatically make the database entries. For example an item with 'no end date' can be assigned an end date of 20 or 100 years, then each year (through cron) an additional year will be added. Thus the end date will always be a certain number of years in the future.

I think for most use cases I have encountered, as long as a certain number of years hence is automatically added to the date is sufficient.

I think this would resolve the infinity problem - yet provide a usable solution for most situations.

artatac’s picture

I am paying a programmer to create a module that runs each monday > looks at recurring events that start anytime during the previous week and move it on by a week. On save, all dates are recreated ensuring that past dates are not stored and enabling me to set the recur occurrences to a 8. If you have recurring dates that DO finish on a particular date then you use the recur until [date] and these are ignored. If there are others who would find this of benefit and are willing to help me recoup my costs via a bounty, I would be happy to release it to the community.

koppie’s picture

@artatac it would be wonderful if you'd be willing to share this excellent module you've created. I'd be happy to post the module on your behalf and give you credit for it.

This is how Drupal works. Sometimes modules are funded and sometimes the developer is unpaid, but everything on Drupal.org is free. You get to benefit from excellent modules like Views and Panels. I've made my own small contributions (themes and a module) and other people are grateful for them. In aggregate, you will benefit because you're still getting millions of dollars' worth of software for free. Other CMS projects aren't as generous; most of the good modules for Joomla cost money. The result is a much smaller, stingier developer community.

If you've already created a useful module, please share it. It will increase your stature in the Drupal community and it's your chance to give back a little bit, in return for all the excellent software you've received for free.

artatac’s picture

Absolutely agree and be sure that anything I produce myself with knowledge freely shared within this excellent community will be shared free of charge with the whole community, as I have also done in the past. :-)

akolahi’s picture

@artatac this sounds great! To make it flexible for various use cases, it would be great if the module could allow for user defined 1) temporary end date / time forward (i.e. in for my use, i would like 10 years in the future to be created), 2) how often to check for the need to push forward the end date.

Might also be great to allow the user the option to not remove previous dates, but only add new dates.

Also, i may have a project coming up that may be able to incur some of the cost.... let me know.

artatac’s picture

We have built in a debug mode where you can override the auto 'lastweek - Monday" and put in any date to look for and the date to move it to that defaults to "this week - Monday" can also br overridden to any date. Also we found that it was necessary to slice it up by days of the week starting monday as many crons have limitations on how long any process is alloed to run. So it initially finds all applicable recurring events that have a monday start date and moves those along then runs a separate job where day is +1, then +2 etc..

I am thoughtful about your 10 years in the future as the whole reason behind the module is that views and date recur cannot cope when the amount of recurring date instances is a large number eg 100s. My client got bored of having to put in recurring events so just set them all to recur until 2016. The result was the site just collapsed.

Our solution is that we, by default show the next 8 weeks, and just keep shifting it on