Add time field to "Additional" repeat dates

HI Enzymes. I noticed the same thing. If you find a solution before I do please post it here :) Cheers.

Hi Enzymes. After playing around with my Custom Content type that uses the date / time module I realized that if you add an additional date and save without clicking the "Add more additions" button the additional date won't disappear. The bug appears to be with the "Add more additions" button so just avoid using it until the next release comes out for the date / time module.

hope that helps.

Subscribing

Subscribing!

We're experiencing the same issue. Our client is making heavy use of the Additional field for repeating dates in the content they've uploaded so far, and this bug is really screwing up our calendar list view. The list is grouped by day, and the repeating events that use the Additional field are showing up in their own day group, instead of being listed with the other events in that day, and are being listed as "All day" instead of at the correct time.

I wish I was more experienced with diving into contrib modules and submitting patches. I'm going to have to figure it out real quick if this bug isn't fixed as we're launching this project in a few weeks.

One other note: our client found an annoying but functional workaround: Instead of crafting your repeating dates using 'Additional', set it to repeat on ALL dates, and then use exceptions to cut out all the dates you don't need. Its a lot more work but it will do the trick until this issue is fixed.

Here's a patch - it adds a from time field to the "additional" field and grabs the duration from the original meeting's duration. It also patches date_ical so the .ics file includes the additional meeting(s) as an RDATE (a warning, though, Mac's iCal doesn't understand RDATE, but Google Calendar and most other do.)

subscribe. Thanks Reinette, will test this today.

Hi Reinette

I notice your patch is to be applied to v2179. But My date code is 6.x-2.7 which seems different.
I am assuming that 2179 is from dev, but I also notice that dev has numerous changes including some related to views which Karen indicates in the latest dev is still a work in progress. Im hestitant to move my code to dev since Im using views heavily in my event processing.

Any guess how safe it would be for me to apply your patch manually to Date v6.x-2.7?

Ah, sorry, that revision number is my internal SVN. It should apply fine to 2.7 - that's what I'm running also.

Ah, and I should note, this patch contains @mjoyce's fix for the "last date not appearing" problem noted here: #337666: Repeat Until date->time defaults to 12:00AM - should be 11:59PM (and so the Repeat is not inclusive of the "repeat until" date).

I applied the patch and the additional date field now has a place to input the time ... but when I save the form the additional date/time doesn't get saved, only the main date/time. Any ideas?

I'd be much obliged if someone could help me get this working, as I'm currently resorting to cloning nodes and changing the date/ time, resulting in duplication.

@djhspence: What version of PHP are you running? Also, how does it save, does it just quietly not work, or do you get an error msg in your log or anywhere else? Do you see any additional entries in the content_date_field (or whatever your field name is called) table in the database, or are they not making it that far? When you re-edit, is the time still there?

I'm running PHP 5.2.17

It seems to just be quietly ignoring my input in the "additional" fields. I set the "From" date and time as normal, leave the other Repeat settings alone except for "Additional" in which I put one or more dates and times. Hit save, and the node displays the main date but not any additional dates. When I edit the node, the values are gone from the "additional" field. When I try to re-add them and save again, the log shows the node has been updated but the dates still don't save.

There is this one entry from my logs which may be relevant:

require_once(.//date_api_sql.inc) [function.require-once]: failed to open stream: No such file or directory in /home/mysite/public_html/drupal-6/sites/all/modules/calendar/includes/calendar_plugin_style.inc on line 125.

But this may have been from before the patched module was properly registered in my system -- I was getting a bunch of different errors before I visited update.php, admin/build/modules and cleared the caches.

Thanks for looking into it!

Whoa. Not sure what happened or if it's relevant, but I now have several hundred log entries saying:

Duplicate entry 'admin/build/panels/layouts/list/%/edit' for key 1 query: INSERT INTO menu_router (path, load_functions, to_arg_functions, access_callback, access_arguments, page_callback, page_arguments, fit, number_parts, tab_parent, tab_root, title, title_callback, title_arguments, type, block_callback, description, position, weight, file) VALUES ('admin/build/panels/layouts/list/%/edit', 'a:1:{i:5;a:1:{s:21:\"ctools_export_ui_load\";a:1:{i:0;s:14:\"panels_layouts\";}}}', '', 'ctools_export_ui_task_access', 'a:3:{i:0;s:14:\"panels_layouts\";i:1;s:4:\"edit\";i:2;i:5;}', 'ctools_export_ui_switcher_page', 'a:3:{i:0;s:14:\"panels_layouts\";i:1;s:4:\"edit\";i:2;i:5;}', 125, 7, 'admin/build/panels/layouts/list/%', 'admin/build/panels/layouts/list/%', 'Edit', 't', '', 136, '', '', '', 0, 'sites/all/modules/ctools/includes/export-ui.inc') in /home/mysite/public_html/drupal-6/includes/menu.inc on line 2461.

djhspence: That's unrelated, that's a weird menu rebuild race-condition error that has a zillion issues posted against it, it's been around forever. It's essentially harmless. Menu rebuilds occur any time you save a view, content-type-setting, or do other various administrative tasks.

I'm running PHP5.3, that may be related to why the patch isn't working for you - I know PHP5.3 has some very specific timezone behaviours.

Also, have you cleared all the caches etc? :)

Thanks Reinette, guess I'll set up a dev box with PHP 5.3 and see if I can get it working there. Unfortunately I may not be able to port it to my live site if I can't get my host to upgrade PHP. I don't have anywhere near the coding chops to see if I can work out the kinks and get it going with 5.2.

And yes, I cleared every conceivable client/server cache and performed every mystical Drupal rite I know of.

#8 did not apply cleanly for me.
Here's a fresh copy.

Depends on (does not include) #337666-18: Repeat Until date->time defaults to 12:00AM - should be 11:59PM (and so the Repeat is not inclusive of the "repeat until" date)

The time value is not being stored consistently for additional dates.
I'm having trouble following the spaghetti to track this down...
So frustrating.

OK - a little more research and a little further down the rabbit hole and I think I've got to the bottom of this.

preface: Check out this primer on RDATE syntax: http://www.kanzaki.com/docs/ical/rdate.html (from RFC 2445).
1. Date repeat module's handling of multiple date additions is currently wrong, according to this RFC.
2. Timezone is unnecessary in an RDATE rule -- we can just use the timezone of the field. Further, specifying the timezone breaks parsing of the RDATE

This patch takes the same approach as #8 with the following changes:

• omit timezone from the RDATE rule
• build and parse RDATE syntax (in date_api_ical_build_rrule() and date_repeat_split_rrule()) in compliance with RFC 2445

Now all the date additions seem to be stored and read properly.

Depends on (does not include)
#337666-18: Repeat Until date->time defaults to 12:00AM - should be 11:59PM (and so the Repeat is not inclusive of the "repeat until" date)

Hi aaron. Thanks for the fix. I assume #24 means that the latest dev now has both your patch in #24 as well as the patch #337666-18 it depends on, or do I have to do some patching as well?

dpatte: no, you should apply (and review) both patches.

I was on 2.7, but took the latest dev today and applied both patches.

Its great. I now have added dates with times, they appear in my calendar, and as well i got the fix that stopped incrementing the end date on each submission.

But one oddity is that if I add two additive exceptions, the second one seems to be correct, but the first one seems to be miscalculating the timezone. This is the case in the calendar as well as in the node display, but if I re-edit the node the values I entered remain as I entered them.

For example: I have my timezone set as America/Montreal which should currently give me UT-4. If I enter 2 extra dates at 4PM the first add shows as 12 noon in the calendar. But the second add shows as 4PM in the calendar.

Here is the date time pattern rule from the db

RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20110714T035959Z;WKST=SU
EXDATE:20110712T000000
RDATE;TZID=America/Montreal:20110710T202300,20110711T162800

In this case I entered 2011/07/10 20:23 and 2011/07/11 16:28 as my added exception dates and times
but they are being displayed as 16:23 and 16:28

ACK - forgot to include the updated patch in #24 - sorry.
You're describing the exact issue that prompted me to create a new patch.

Depends on (does not include)
#337666-18: Repeat Until date->time defaults to 12:00AM - should be 11:59PM (and so the Repeat is not inclusive of the "repeat until" date)

Much better. Thank you. Very good work!

I still have an issue, but I can live with it. If i entered 12Am (blank) for an added date, then people in other zones see it as 12AM offset to their own zone (ie 1 AM for example), instead of seeing it as 'all day'. I am using the 'user tz' by the way.

So, is it correct to say that with these patches, we can't add a different ending time or time span? I often run into events which have shorter hours on the first or last day of a multi-day event (either starting later or ending earlier).

tweten: yes, that is correct.
Patch #30 implements a relatively minor change to an existing form element.

Adding a "to date" for repeating date additions is technically possible, but would constitute significantly more work.
We should try to get this patch in first, then tackle varying timespan elsewhere.

Seems like for a "minor change", there has been quite a bit of work put in already. I appreciate all the effort.

Thanks for the TZ catch, @aaronbauman! I've tested #30 and it's working great.

I am having this problem. I would love to see these fixes get moved into a release.

I am assuming the patch is for 2.x-dev and not 2.7.

And thanks for all the hard work!

tweten: there's definitely been a lot of effort, but in this case it only amounts to 6 lines of code that need to be changed. The patch in #30 doesn't even add any lines.

ice5nake: yes, 2.x-dev

Maybe one or two more reviews and we can bump this to RTBC

Does anyone have a working patch for 7.x? Should I opena separate issue?

I put together a patch for the 7.x-2.x-dev branch. This patch fixes the timezone handling of exceptions such that they are not shifted one day before on GMT+X timezones.

It also includes the changes in #30 allowing time selection for additions and expands on #337666: Repeat Until date->time defaults to 12:00AM - should be 11:59PM (and so the Repeat is not inclusive of the "repeat until" date) to actually include UNTIL time fixing.

Regressions: the js popup input doesn't work anymore, I still haven't find out why.

Could any module maintainer please review and comment on this patch? I'm not really confident with the date module internals, but these changes seem to work fine for my setup.

Sorry, wrong patch format.

patch in #6 for #1243022: Javascript error fixes the date/timepicker popup

Patch #30 worked against my 6.x-2.x-dev install. It added another field for the start time of the event, which does mean that we can get the time working correctly. It seems to me that this would be helpful to commit to the module when possible.

I'm curious about the relationship between this issue and this one:

http://drupal.org/node/1300274

That one solves the problem of additional dates not displaying the time relative to midnight instead of the same time as the repeating date.

Shai

djhspence: a little late, but did you select any repeat frequency? It seems to be designed not to save the contents of the Repeats fieldset unless a frequency/period is set, so adding an addition without specifying any repeat rule which it's in addition to won't work.

Shai: None, I don't think, as additional dates were left out of the latest major of Date and this thread adds it back in.

The issue at #1300274: Request for Backport: Repeat Date "Additions" Display Wrong Time sets the fields to use the right time (the original time), and that is done in both D6 and D7 now. I don't intend to add in the ability to set other times than the original time for additions. Or at least I don't consider that a 'bug', let alone a critical bug. I consider that a feature request.

This is a long thread. If the remaining issue is a request to add a time to the addition, the title and status need to be adjusted and I need to know what patch is needed after the commits I just made to backport some D7 repeating date code to D6. If I'm misunderstanding the issue I need clarification.

The concept of adding additional dates with their own time allows you to use this field type for both repeating date-times of a series, or random date-times. There seems no other way of handling that scenerio except by the patch in #30, so for now I guess I wont be upgading to the latest version.

A feature like this would be indispensable for events like movies or plays that may have different show times on different days, without any logical sequence. As it stands, we have to clone events such as these and set the datetime for each new node - which means a lot of work if the description needs to be updated on all the nodes, for instance.

Even if it is a feature request, @KarenS, it's been tested by multiple people and it doesn't seem to have any problems... And even if it's a feature, it's one that's critical to my users; as djhspense points out, its workaround is cumbersome and terrible.

The patch in #30 seems to be RTBC at this point...

Would love to see these patches applied to Date Repeat API. This functionality would be so helpful.

Has anyone tried to apply the last patches to v2.9?

I'm still on v2.7+dev and seem to have date patches in
date_repeat.module (for $RDATE)
date_repeat_calc.inc (to set the time to 23:59:59)
date_repeat_form.inc (to add form elements for hh and mm)
date_api_ical.inc (also for $RDATE)

Have any of these issues been fixed in 2.9, or should I manually merge all the same patches in to 2.9?

Ok, I'm making this D7 so we can get some traction on it.

KarenS, the issue is as follows: if you need to add an additional date to a series of meetings/events (say one got rescheduled), you can only do so if it's at the same time as the original repeating sequence. In most of the orgs I've been in, that rarely happens -- an additional event that's still part of the series will be at an out-of-sequence time as well as day. I'm not sure how to re-title this issue; the title sums it up nicely.

This is a feature request, but it's one that's had a working patch for awhile. Do you need me to re-roll it for the latest 6? I haven't looked at the 7 codebase for date, does it need to go there first? What needs to be done? The actual patch is pretty modest, and there are both 6 and 7 patches here already.

Actually, Renee, if you could re-roll it into 6 I could certainly use it. Im currently stuck at a variation of v2.7 as mentioned above, and not sure which patches in my 2.7 are part of this change. My goal is to move to D7, but I'd like to get all my modules up to the latest D6 first, and this is the last one that is holding me back.

i don't know how to make patch.
This how i solved it using Drupal 6

1) This will add Time Field With Date Field to additional.
2) Edit Still working
3) Display Output at View Node Working.
4) Date Save Correct in Database.

File: sites\all\modules\date\date\date_repeat.inc
Version:6.x-2.9
Line: 186
Code: $additions[] = date_format($date, 'Y-m-d');
New code: $additions[] = date_format($date, 'Y-m-d H:i');

----------------------------------------------------------
File: sites\all\modules\date\date_repeat\date_repeat_calc.inc
Version:6.x-2.9
Line: 368
Code: $date = date_make_date($addition . ' ' . date_format($start_date, 'H:i:s'), $timezone);
New code: $date = date_make_date($addition, $timezone);

----------------------------------------------------------
File: sites\all\modules\date\date_repeat\date_repeat_form.inc
Version:6.x-2.9
Line: 218
Code: '#date_format' => !empty($element['#date_format']) ? date_limit_format($element['#date_format'], array('year', 'month', 'day')) : 'Y-m-d',
New code: '#date_format' => 'Y-m-d H:i',

----------------------------------------------------------
File: sites\all\modules\date\date_repeat\date_repeat_form.inc
Version:6.x-2.9
Line: 348
Code:$rdate_element['#date_format'] = date_limit_format($element['#date_format'], array('year', 'month', 'day'));
New code: $rdate_element['#date_format'] = 'Y-m-d H:i';

Lovegame, see "Create a patch." http://drupal.org/project/calendar/git-instructions

Putting this back, it got changed. Leave this as 7 - anything we come up with can be backported. I'll provide a 7 patch shortly that updates #39.

The iCal timezone issue addressed in that patch should get its own issue, as it's a bug.

The previous patch ( #60 ) was causing syntax error. I applied some corrections.

It adds an hour granularity to inclusion dates but does not collect end date, so it does not allow an event to be longer on a particular date :(

Thanks, barig. For my use-case the meetings will always be the same length as the original, and that requirement does add a bunch more complexity.

Thanks Bariq. I tried to apply the patch in #62, but I'm getting the following errors:
error: sites/all/modules/contrib/date/date_repeat/date_repeat_form.inc No such file or directory
error: sites/all/modules/contrib/date/date_repeat_field/date_repeat_field.module No such file or directory

I'm applying the patch from sites/all/modules/date/date_repeat/. Is that right, or is this intended to go in the root folder?

[I just noticed that I do not have a "contrib" directory in sites/all/modules. Drupal has been installing modules directly into the sites/all/modules folder. This may be the issue.]

Scratch the above (#65). I got the patch installed and it's working!

Notes:

1. I deleted the "contrib" directory reference in the patch, because I have no contrib directory
2. I moved the patch to the site root and applied from there

Hope that helps anyone else running into issues. Great module and great patch folks!

Barig: best-practice for patches is they should always be relative to the module's root, rather than the Drupal site root :) I'd done mine wrong too. Oops.

Can a maintainer take a look at this, please? It's been sitting here for a very long time, represents a small change in code for a huge change in usability, and also represents lots of community work to improve module functionality.

@Karen S: "If the remaining issue is a request to add a time to the addition, the title and status need to be adjusted and I need to know what patch is needed after the commits I just made to backport some D7 repeating date code to D6."

This has been done. Thanks!

Tested and it works!

This desperately needs to be looked at. Repeat Dates with different timing is game changer for anyone looking to add a large amount of events.

Please review.

updated patch to work from root but this isn't providing the solution I was looking for :(

The functionality I was looking for is multiple repeating dates.

example:
every Tuesday at 11
every Wednesday at 2pm
Every thursday at 5pm

kclarkson, is #1437220: Unable to select multiple byday,bymonth,etc. rrule part values in repeating dates this what you need?

@renee S

No. The functionality I need is to be able to set different AM / PM times for each repeating day.

So for example:
every Tuesday at 11
every Wednesday at 2pm
Every thursday at 5pm

Right now I can select different repeating dates but they all have the same time.

eta: I'm not really sure why this keeps failing tests, what's failing doesn't seem to be related to the changes.

Trying again... it seems testbot was rejecting stuff it shouldn't.

i don't understand. this has been working for a long time and tested

vijaycs85, can you clarify why this needs work? This should have been committed a long, long time ago.

Sorry for the silent status change... just set to needs work as I don't see any patch to review or commit.

#72 is working for me in production...

72: d7-1053158-date-additional-2.patch queued for re-testing.

Ok, we need to fix the test fails to get this code in. For more details about d.o issue status - https://drupal.org/node/156119

Yeah, I don't understand those fails, they seem to be false positives.

Did anything ever happen with this? I see that the test bot says it fails, but there are people who insist the patch works in production. This is invaluable functionality and should be addressed... I want to believe the patch is safe to use, but is it really?

In doing the simplytest.me, it looks as if the patch doesn't respect the time increments specified in the field settings (15 min increments, 10 min, etc.). That's really the only problem I could find.

Also—and I think this is probably intended—there is no way to specify a different length of time in the exceptions (e.g. if the original time span is an hour long, you can't change it to an hour and a half).

I feel I should mention some further observations I've made while interacting with this patch on my own sandbox site (patch applied cleanly and quickly, btw).

1. I found that the additional time functionality is not intuitive if you happen to use it with the "Date All Day" module (date-repeat-patch01.png attached to issue). The fields *require* you to enter an hour and minute—if you have the all day checkbox selected, you have to specify 12:00am for the (All Day) text to display correctly.
2. If you do specify a time in the included date and have the all day checkbox selected, it will show the time you specified in 24-hour format—without am or pm(date-repeat-patch02.png attached to issue).
3. I've also found that the patch doesn't respect granularity down to seconds (date-repeat-patch03.png attached to issue). I'm assuming there's probably not a lot of use cases of people using seconds, but this might be something that needs to be checked if we want to offer this additional time field for repeats...

I really wish I could understand the code behind the module so that I could be of better help... I felt I should at least mention these "conflicts" here for anyone seeking to use this patch.

Using Drupal 6.30 and Date API 6.x-2.x-dev, I found that lovegame's fixes in #55 worked for me... almost. The only problem with them was that they didn't take timezones into account. The attached patch applies lovegame's work in a timezone-aware way (afaict).

I am using this patch successfully and just ran into a situation where I need to change the end time of an additional date, because it's a shorter event on one of the dates. Is there no solution? I'm having to tell my client I can't do it...

@tchopshop, adding a field for end-time is nontrivial, because RDATE just takes a start time, not an end time. The spec doesn't expect repeating events to have different lengths.

I had been using #72 in production for about 8 months, but it's not working now. I'm really not sure what changed. Now, we're getting PHP notices/warnings on save.

I tried to create an event on 6/22/2015 @ 20:00 that would repeat weekly on Monday, stopping after 3 occurrences. I used "Include dates" to add events on 6/24/2015 and 6/30/2015. When I clicked "Add addition" to get the second "Include date", I got this (after the Ajax ran):

Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Warning: date_format(): The DateTime object has not been correctly initialized by its constructor in _date_repeat_calc() (line 393 of sites/all/modules/contrib/date/date_repeat/date_repeat_calc.inc).
Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).

After saving, I got this:

Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Notice: Undefined index: #timepicker in date_popup_time_format() (line 236 of sites/all/modules/contrib/date/date_popup/date_popup.module).
Warning: date_format(): The DateTime object has not been correctly initialized by its constructor in _date_repeat_calc() (line 393 of sites/all/modules/contrib/date/date_repeat/date_repeat_calc.inc).
Warning: date_format(): The DateTime object has not been correctly initialized by its constructor in _date_repeat_calc() (line 393 of sites/all/modules/contrib/date/date_repeat/date_repeat_calc.inc).

And the additional repeated items are getting filled in with the current date/time:

Repeats every week every Monday 3 times . Also includes Wed Jun 24 2015, Tue Jun 30 2015.
Friday, June 19, 2015 - 15:19 to 16:19
Friday, June 19, 2015 - 15:19 to 16:19
Monday, June 22, 2015 - 20:00 to 21:00
Monday, June 29, 2015 - 20:00 to 21:00
Monday, July 6, 2015 - 20:00 to 21:00

I was able to recreate this on a pretty vanilla installation running on both PHP 5.4 and 5.5. Without the patch, I get no notices/warnings and it does created the event correctly (with repeats).

Could someone please update the issue summary with a list of remaining issues & put together a fresh patch against the latest -dev? Thanks.

Here's an updated patch against 2.x HEAD.

Seems there was no resolve to this? I applied the #98 patch and the new field for times shows up however on the save the form and display updates the first instance to today's date and time and the added date and time does not show. Any solutions would be greatly appreciated.

Here's a fresh patch against the latest -dev (re-rolled #98) and also I've fixed the issue mentioned in #102.

Great work!

Although only the php5.3 text finished, here a first writeup what failed:

5 3 Date.DateRepeatFormTestCase
✓ - setUp
✓ - testDateRepeatForm
✓ - createDateField
✓ - dateForm
✗
verifyDateForm
exception: [Notice] Line 445 of sites/all/modules/date/date_repeat/tests/date_repeat_form.test:
Trying to get property of non-object

exception: [Notice] Line 451 of sites/all/modules/date/date_repeat/tests/date_repeat_form.test:
Trying to get property of non-object

  function verifyDateForm($edit) {
    $title = $edit['title'];
    $node = $this->drupalGetNodeByTitle($title);

    $this->drupalGet("node/{$node->nid}/edit"); // L445 - $node->nid?

    foreach ($edit as $field => $value) {
      $this->assertFieldByName($field, $value);
    }

    $this->drupalPost("node/{$node->nid}/delete", NULL, t('Delete')); // L451 - $node->nid?
    $this->assertRaw(t('Date %title has been deleted.', array('%title' => $title)), t('Deleted Date content.'));
  }

cannot get node by title?

Right, i guess we have to fix \DateRepeatFormTestCase::testDateRepeatForm so that the exclude and include inputs have hour and minute.

✗
drupalPost
exception: [Warning] Line 2115 of modules/simpletest/drupal_web_test_case.php:
Invalid argument supplied for foreach()

this is a consequence of L451 above.

✓ - deleteDateField
✗
ate_popup_time_format
exception: [Notice] Line 259 of sites/all/modules/date/date_popup/date_popup.module:
Undefined index: #timepicker

  function deleteDateField() {
    $this->drupalGet('admin/structure/types/manage/date/fields');
    $this->clickLink('delete');
    $this->drupalPost(NULL, NULL, t('Delete'));
    $this->assertText(t('The field Test has been deleted from the Date content type.'), t('Removed date field.'));
  }

function date_popup_time_format($element) {
  return date_popup_format_to_popup_time(date_limit_format($element['#date_format'], date_popup_time_granularity($element)), $element['#timepicker']);
}

Hmm, interesting, the popup timepicker has hiccups. Gut feeling: Maybe we should use the exact time format of the start and end date instead of hardcoding 'Y-m-d H:i' (which is bad anyway).

I also did a manual test. Same '#timepicker' notices as described above.

And another "needswork": Include dates does have a timefield now, but Exclude dates does not.(edit: exclude dates don't need a time, they exclude all day ;-)

I added a check to avoid the notices...

@valderama: Thanks for your work on this!
Please note that patches must be based on the module dir.
(I can use yours with the -p7 option but the testbot can't.)

Let's try slaying this thoroughly. Patch flying in with a rework that has no hardcoded formats.

Fixed tests.

...and special treatment for the time widget in tests.

CI coughs? try again.

OK, 2 notices and warnings left, let's hunt them down the next days...

✗	
verifyDateForm
exception: [Notice] Line 449 of sites/all/modules/date/date_repeat/tests/date_repeat_form.test:
Trying to get property of non-object

exception: [Notice] Line 455 of sites/all/modules/date/date_repeat/tests/date_repeat_form.test:
Trying to get property of non-object

✗	
drupalPost
exception: [Warning] Line 2115 of modules/simpletest/drupal_web_test_case.php:
Invalid argument supplied for foreach()

That's weird... false positives?

Nope, completely reproducible.

AAh, got the text time format in test wrong.

Banzai! Anyone to test the patch and set RTBC?

Servus Axel,

I have tested your patch, and it works fine here. As also tests are green, I'd call it RTBC.

Best,
Walter

NOTE: At the time I have written this comment, all tests did pass. No idea why they fail now.

Works, plase commit!

Checked that the failing PHP5.4 tests of this patch are just those tests that fail for the unpatched module supposedly as for #2646646: Tests are broken on current 7.x-2.x branch, so patch-wise everything is green. But let's see what happens after that issue (which is RTBC now) is committed.

Great feature and a lot of work is done but even though time is calculated correctly, unfortunately, I have to say that there is an issue with this patch. In the case of date_all_day submodule enabled and checked – time input appears for additions. In my opinion, it should be hidden for additions as well and here another issue comes up. Drupal Form API "#states", that is the mot obvious solution, does not work correctly with AJAX framework, so need to take a closer look.

I think this case should be covered as well in this issue, what do you think guys?

@l0ke: it's a 6 years old issue... :) What about to put yours to another one?

Patch for this issue adds a functionality that, generally speaking, contains a bug – should it be resolved right from the beginning? I think – Yes, no matter how old this issue is.

Thanks @l0ke for that observation.

This should be simple (and we won't need state-api for it) as the old code in fact created all-day entries and we only have to check if it's an "all-day" date field and fall back to the old behavior.

Ok, I've found another thing (or feature request?): what if when someone checked the "End Date" option? So what about the setting of the additions's End Date?

Neither of that, repeat rules build in the way that each occurrence of repeat dates always have the same duration.
E.g. you set start date Jan 17 10:00, end date Jan 18 10:00 – that means that each occurrence will start at 10:00 and ends 10:00 next day.
Current issue provides a feature to change the start time. That means you can say that start date will be Jan 20 11:00 => end date would be Jan 21 11:00.

So the situation you've described is not the case.

patch needs a reroll. I will reroll it

looking into this now

Here is the rerolled patch

Would help understanding the issue, motivation and how to test it

I am using this patch with multiple repeated and recurring dates. Seems to work well, I'll add more details about the difference before and after in the rrule row of the date field.

TO see what this patch does to the database, look at the rrule column in the date field table.

basically it adds a time field to the repeat date, stores it in the rrule column.

It was quite complicated to figure out all the pieces but this patch definately got the job done for my client.

TO see what this patch does to the database, look at the rrule column in the date field table.

basically it adds a time field to the repeat date, stores it in the rrule column.

Thanks to everyone above! if you want to see this patch working, have a look here:
https://polymtl.ca/calendrier École Polytechnique de Montréal

Here's a better example of the repeat dates in action:

https://www.polymtl.ca/calendrier/evenements/conseil-academique-1?start=...

click the link '8 autres dates' it will expand and you'll see the repeated dates.

The repeat date time does work thanks to this patch, however it isn't visible on this page.

Just the tests.

Due to some code sniffer style related changes (that broke the tests in HEAD BTW) that were done previously, the test code had to be re-rolled.

New patches for both rerolling 135 (entire solution) and also rerolling 141 for the tests only patch

passes testing, tests-only test fails.

There's been no negative feedback in over 4 years.

Marking this as RTBC