- 24 Jun, 2014 1 commit
-
-
t0xicCode authored
Thank you t0xicCode for this patch!
-
- 30 May, 2014 3 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
-
- 27 May, 2014 1 commit
-
-
Robert Rollins authored
-
- 08 May, 2014 1 commit
-
-
Robert Rollins authored
User RedEight pointed out that I messed up the parse regex for UNTIL values when I made the recent change regarding DATE-type UNTILs. That's fixed, now. In addition, I tweaked the iCalcreator version detection regex to be a bit more forgiving of any possible changes the author makes in his version definition code.
-
- 23 Apr, 2014 1 commit
-
-
Robert Rollins authored
-
- 18 Apr, 2014 1 commit
-
-
Robert Rollins authored
-
- 16 Apr, 2014 6 commits
-
-
Robert Rollins authored
There's a new setting on the "iCal parser" settings page, which lets you set an integer number of days. Events which ended more than that number of days before the import will be skipped.
-
Robert Rollins authored
This makes it consistent with the "DateField: Repeat Rule" feeds target offered by the Date module. It also pushes the source up next to the "Date: Start" and "Date: End" sources, which helps you find it when you're setting up your mapping. This is only a UI change.
-
Robert Rollins authored
According to the iCal spec, the UNTIL value of an RRULE must be specified in UTC. But certain iCal feed creation tools don't respect this rule, and instead specify the UNTIL value in local time. Since all the other code that Date iCal utilizes to parse RRULEs expects the UNTIL value to be in UTC, this go badly when it's not. In order to get around this issue, I've added an option to the iCal Parser settings, which allows users to tell Date iCal that they expect the UNTIL values in their feeds' RRULEs to not be in UTC. With that option enabled, Date iCal will treat the UNTIL date as being in the same timezone as the event's DTSTART.
-
Robert Rollins authored
Upon further research, I discovered that my previous write-up about this setting was incomplete and partially incorrect. I also discovered the glaring bugs in the "Date's time zone" setting, so I added a warning against using it.
-
Robert Rollins authored
Date iCal doesn't currently use this new mechanism (I originally created it for a feature that ultimately didn't end up needing it), but it may be helpful in the future for when one handler needs to know about the results from a previous handler's pass over the same event.
-
Robert Rollins authored
-
- 14 Apr, 2014 1 commit
-
-
Robert Rollins authored
All day events which start on the last day of a month and don't have an end date specified were broken, due to a silly mistake I made in the DTEND emulation.
-
- 10 Apr, 2014 1 commit
-
-
Robert Rollins authored
-
- 31 Mar, 2014 1 commit
-
-
Robert Rollins authored
This hook allows modules to alter the final data array for each event, just before it gets sent through the rest of the Feeds processing steps to be turned into a node. The context array is what separates this hook's functionality from what users can do with Feeds Tamper.
-
- 24 Mar, 2014 1 commit
-
-
Robert Rollins authored
Made a few other improvements to the README while I was at it.
-
- 20 Feb, 2014 1 commit
-
-
Robert Rollins authored
-
- 03 Feb, 2014 3 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
By using the amazing, free database of Windows timezone names curtesy of the CLDR project (http://cldr.unicode.org), I was able to add support for the non-standard timezone names created by Microsoft Outlook. Hopefully, the "not a valid timezone" error will now be much less common.
-
- 13 Dec, 2013 1 commit
-
-
Reinette authored
-
- 09 Dec, 2013 1 commit
-
-
Robert Rollins authored
-
- 04 Dec, 2013 1 commit
-
-
KevinPaxman authored
-
- 26 Nov, 2013 1 commit
-
-
Robert Rollins authored
The Date Repeat module’s date_repeat_build_dates() function does not support RDATEs and EXDATEs defined as separate properties, as well as being a bit buggy in other ways. So I copy-pasta’d it and made the necessary fixes. I wanted to add support for EXRULEs, but it’s more complicated than I expected. So since no one has actually asked for it, I left it as a TODO.
-
- 18 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
Date iCal 3's use of the Libraries APIs was slightly less awful than 2's, but it would still fail to properly detect an incorrectly installed iCalcreator.
-
- 12 Nov, 2013 1 commit
-
-
Robert Rollins authored
This is a forward-port of the fix that I just submitted to the 2.x branch.
-
- 11 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
Because OSX uses a case-insensitive file system, git didn't pick up the change I made when I re-wrote the parser. In retrospect, I probably should have chosen a totally new name for the feeds parser, but the existing filename *was* the most appropriate name for the new class, just with different capitalization.
-
- 05 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
As jakemonO pointed out, the Calendar will not display All Day events which have no end date value, which means that Date iCal's method of leaving off the end date for single-day All Day events was a really bad idea. Fortuantely, setting the end date to the same day as the start date makes the date node display correctly for single- day events, which was the reason that the end date was being left off in the first place. This means that every All Day event can simply have it's end date rewound by one day, and all is well in both the node display and the Calendar.
-
- 04 Nov, 2013 1 commit
-
-
Robert Rollins authored
User oskar_calvo discovered that if you update Date iCal from 1.x, but don't also install the Libraries module, you'll get a fatal error when Date iCal attempts to check for the iCalcreator library, because the libraries_detect() function doesn't exist. Now, you'll instead see an error in the site requirements.
-
- 29 Oct, 2013 1 commit
-
-
Robert Rollins authored
-
- 28 Oct, 2013 4 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
Rather than defaulting an an illegal value, the Fields plugin's settings form now offers "First populated Date field" as the default option for "Date field". Using this option will tell Date iCal to look through all the fields in the View until it finds a populated Date field, and use that field. So, if there are two Date fields specified in the view's FIELDS setting, and at runtime the value of the first one is empty (e.g. because the node doesn't use that field), then the second Date field's value will be used.
-
Robert Rollins authored
The update hook now also checks for importers which are set to the new parser, but still have un-capitalized source keys. This will help users who forget to run the database update before manually fixing the missing DateIcalIcalcreatorParser warning.
-
- 25 Oct, 2013 1 commit
-
-
Robert Rollins authored
This commit adds the migration code that converts all Feeds Importers which used the DateIcalIcalcreatorParser plugin to use DateiCalFeedsImporter instead. The old classes have been removed.
-