Posted by Tigger08 on February 6, 2011 at 11:18pm
14 followers
Issue Summary
I have created a content type Event using the CCK, Date and Calendar Module. If I set the repeat date using a frequency the display is correct with all the dates in the Node as well as the Calendar. If I use the Additional dates in the repeat function the dates just disappear and there is no indication of those dates either on the node or in the calendar view. Please help.
Comments
#1
HI Enzymes. I noticed the same thing. If you find a solution before I do please post it here :) Cheers.
#2
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.
#3
Subscribing
#4
Subscribing!
#5
Has anyone come up with a solution for repeating dates and additional random dates. The additional dates now appear but do not hold the time. I have a calendar that has only start time and all additional dates added show (all day) instead of the time. I tried to circumvent this by using two cck date fields in my events. However the views display will not not merge the two fields and display by date. It lists all the dates of cck field 1 and all then all the dates for the second field. I fail to believe that there is no good solution to have repeating date patterns and random dates for events in the humongous drupal world.
#6
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.
#7
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.
#8
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.)
#9
#10
#11
subscribe. Thanks Reinette, will test this today.
#12
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?
#13
Ah, sorry, that revision number is my internal SVN. It should apply fine to 2.7 - that's what I'm running also.
#14
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).
#15
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.
#16
#17
@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?
#18
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!
#19
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.
#20
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? :)
#21
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.
#22
#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)
#23
The time value is not being stored consistently for additional dates.
I'm having trouble following the spaghetti to track this down...
So frustrating.
#24
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:
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)
#25
#26
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?
#27
dpatte: no, you should apply (and review) both patches.
#28
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.
#29
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
#30
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)
#31
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.
#32
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).
#33
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.
#34
Seems like for a "minor change", there has been quite a bit of work put in already. I appreciate all the effort.
#35
Thanks for the TZ catch, @aaronbauman! I've tested #30 and it's working great.
#36
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!
#37
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
#38
Does anyone have a working patch for 7.x? Should I opena separate issue?
#39
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.
#40
Sorry, wrong patch format.
#41
patch in #6 for #1243022: Javascript error fixes the date/timepicker popup
#42
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.
#43
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
#44
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.
#45
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.
#46
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.
#47
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.
#48
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.
#49
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...
#50
Would love to see these patches applied to Date Repeat API. This functionality would be so helpful.