timestamp mapping: date_modify() expects parameter 1 to be DateTime, boolean given [#450158]

Hi,

I'm trying to import an iCal using iCal parser and feedapi_mapper. I started writing this issue under that project, but then realised as the error is reporting from feedapi_mapper I better come here.

I've tried it with both my own diary (which generates icals readable elsewhere) and with http://www.mozilla.org/projects/calendar/caldata/EnglishHolidays.ics

I get this error for (every/several) entries:

warning: date_modify() expects parameter 1 to be DateTime, boolean given in .../modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 76. 
warning: date_modify() expects parameter 1 to be DateTime, boolean given in .../modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 77.

(I've truncated the server path)

The node's are created with the correct start and created dates (dtstart and dtstamp) but the end date is being set to todays date at 00:00.

Having looked at the code, parameter 1 is the $date variable, which is the result of $date = date_create($datetime, timezone_open('UTC')); //line 67

date_create by definition returns a DateTime object on success (as the code is expecting) or FALSE on failure (hence the unexpected boolean).

I'm stuck beyond this point as I don't know drupals internals enough to work backwards from this point to succesfully echo() what $datetime it is trying to parse - I guess the output buffering is getting in the way.

Any ideas?

Peter

Comment	File	Size	Author
#12	feedapi_mapper-450158.patch	1.33 KB	zserno

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

alex_b CreditAttribution: alex_b commented 30 April 2009 at 23:54

Version:

6.x-1.0-beta7

» 6.x-1.x-dev

I committed extensive fixes to date mapper today #215979: Create a CCK date field mapper - can you try this with the latest DRUPAL-6--1 version from CVS?

Comment #2

howartp CreditAttribution: howartp commented 1 May 2009 at 17:38

Hi alex_b,

I've just downloaded beta9 - is this the correct version you wanted? Although I know what CVS is, I've never used it for download or upload; I leave that to developer people.

If beta9 is correct, I now get:

Fatal error: Cannot access empty property in .../modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 112

when refreshing the feed (having 'removed all items' first).

Peter.

Comment #3

howartp CreditAttribution: howartp commented 1 May 2009 at 17:52

Having looked into this, line 112 is:

    $node->$field_name = array($date->value);

Now $date->value is set above on lines 107-108:

  $date->set_value('timezone', $timezone);
  $date->set_value($sub_field, date_format($value, DATE_FORMAT_DATETIME));

It's perhaps interesting that both line 107 from beta9 and line 67 from beta reference timezones?

I don't know what to do about it though. :)

Peter

Comment #4

howartp CreditAttribution: howartp commented 2 May 2009 at 14:34

I've trimmed the ical down to one event as follows:

BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTAMP:20070418T125313Z
UID:uuid1176898847300
SUMMARY:Good Friday
DTSTART;VALUE=DATE:20090524
DTEND;VALUE=DATE:20090525
END:VEVENT
END:VCALENDAR

Then using a bit of PHP I've asked Drupal what is in $date->value:

date >>> DateTime:02/05/09 02:32:52 
date2 >>> DateTime:02/05/09 02:32:52 
offset >>> 3600 
offset2 >>> 3600 
value is empty. 
value2 is empty. 
timezone >>> Europe/London

So it is value and value2 that are empty, causing the error.

What should value and value2 contain?

Peter

Comment #5

howartp CreditAttribution: howartp commented 3 May 2009 at 14:26

Right, I'm getting somewhere. My parser etc is now creating the correct date nodes with the correct times. I started back with Beta7 as that gave me working date codes (albeit with the wrong times) and valid fields to map to in the mappings page. Beta9 just threw a fatal error and the mapping page gave me all sorts of wierd mapping options rather than the basic field_date options.

The first issue with Beta7 is that line 67 uses date_create on $timezone, but this fails and returns false. The reason being the preg_match on line 63 is stripping out the -mm from yyyy-mm-dd; the updated preg_match in beta 9 (ie ending in a $) fixes this issue.

The second issue is line 89 - someone has previously commented out the end_datetime line at line 90, leaving start_datetime, but what is actually needed is $sub_field instead of either start_ or end_datetime. Again, this is fixed in beta 9.

At this point, all nodes will have the start_datetime showing today 00:00 and the end_datetime will be the start_datetime. Perfectly sensible when you follow the logic of the code.

I had to replace line 92 from beta7 with lines 111-123 from beta9.

This gives me nodes with the correct start_ and end_datetime values.

I now have one issue left that I know of - repeating events aren't repeated. Feedapi_mapper_date_ical() contains the repeat rules, but this function never gets called, either in beta7 or in my modified version of beta7. (I put a drupal_set_message call in at line 113 and 115 - before and after the RRULES if statement - but neither of the calls provided any output. The drupal_set_message function is what I've been using to diagnose the issues, show me values of variables etc)

I'll carry on playing with it, and try following through beta9 to see what happens.

Peter

Comment #6

howartp CreditAttribution: howartp commented 3 May 2009 at 22:38

Status:

Active

» Fixed

It's me again.

I need to apologise to anyone reading this. I've just discovered (having read the whole of http://drupal.org/node/215979) that I was using the wrong mappings. I'd been mapping options->VEVENT->DATE->DTSTART->datetime to my field_date (date): Start Date (Date and time), etc.

When using an ical feed, you should instead map:

options->VEVENT: directly to field_date (date): iCal VEVENT

So I'm now successfully using beta9 as published; I still don't have RRULES working, but I can look into that properly now I'm on the latest version.

I'll close this issue as fixed (by Beta9) and start a proper issue for RRules if I'm stuck.

Peter

Comment #7

alex_b CreditAttribution: alex_b commented 4 May 2009 at 14:05

Status:

Fixed

» Active

Shouldn't this be documented?

Would you be up for writing a sentence or two on how to use the date mapper for README.txt ? I would appreciate it a lot.

Comment #8

howartp CreditAttribution: howartp commented 4 May 2009 at 19:34

Hi Alex,

Hmm, I'll have a go at something.

Give me a couple of days.

Peter

Comment #9

howartp CreditAttribution: howartp commented 5 May 2009 at 23:05

Alex,

Just found this (which I haven't seen in the week or so I've been looking around Drupal regarding icals etc):

http://drupal.org/node/341716

Do we all have permission to just edit such content, or do I need to go to the original author and offer an update?

It is basically what I was going to write, but as someone has commented, it is out of date regarding icals mapping to vevents.

Peter

Comment #10

alex_b CreditAttribution: alex_b commented 9 May 2009 at 14:24

Peter - please go ahead and edit the handbook page you found. This would indeed be of great help!

Comment #11

TKS CreditAttribution: TKS commented 23 July 2009 at 19:44

Hi All. I can report that this is still an issue with 6.x-1.0-beta12 (and 6.x-1.7-beta3 of FeedAPI).

I can map options->timestamp to Published date (node) with no problem, but every attempt to map to my CCK Date field throws this error or some variation on it.

For example...

When I Map to field_pubdate (date): Start Date (date and time), I get the following:
warning: date_format() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 113.

When I Map to field_pubdate (date): Start Date (timestamp), I get the following:
warning: date_timezone_set() expects parameter 2 to be DateTimeZone, string given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 142.

And when I Map to field_pubdate (date): Start Date (date only) -- as my publication date doesn't require time -- I get:

# warning: date_offset_get() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 409.
# warning: date_offset_get() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 410.
# warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 411.
# warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 412.
# warning: date_format() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 413.
# warning: date_format() expects parameter 1 to be DateTime, boolean given in /home/newdev/public_html/sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 414.

Depending on the setting, my CCK date field would either wind up empty or defaulting to today's date.

I'm assuming this is related to the fact that Node's created-date is saved as a unix timestamp that's in a simple string, while a CCK datefield is a string date value that's in a more complex array. IE, here's what shows in Dev Load once I've manually input a date:

#
field_pubdate (Array, 1 element)
      0 (Array, 4 elements)
            value (String, 19 characters ) 2009-04-04T00:00:00
            timezone (String, 16 characters ) America/New_York
            timezone_db (String, 16 characters ) America/New_York
            date_type (String, 4 characters ) date | (Callback) date();

And for what it's worth, the feed I'm trying to pull in is from a Drupal 5 site -- so there shouldn't be any funkiness to the timestamp there.

But I'm stumped -- and happy to help test if folks have ideas. Thanks in advance for any suggestions!

Comment #12

zserno CreditAttribution: zserno commented 13 August 2009 at 13:58

Category:	support	» bug
Status:	Active	» Needs work

File	Size
feedapi_mapper-450158.patch	1.33 KB

I can confirm all the error messages from #11.
I tried to map a single timestamp using Start Date (timestamp), but got the same error (warning: date_timezone_set() expects parameter 2 to be DateTimeZone, string given...).

I found that date_timezone_set() gets a string as parameter 2, so I added a timezone_open() call around it. It solved the error message, but my date field's value was still incorrect.

So after some further investigation I found that there was no support for timestamps. Attached a patch that handles it (diffed against DRUPAL-6--1).
Note: it only works if you map to timestamps but other error messages from #11 will probably need more work.

Comment #13

TKS CreditAttribution: TKS commented 13 August 2009 at 17:25

Confirming that zserno's patch works like a charm.

So long as the mapping destination is a "datestamp" CCK field, the (timestamp) option is chosen the target pulldown, my test feed now pulls both Start and End dates perfectly.

Comment #14

Aron Novak

Hungarian

Hungary, Budapest

CreditAttribution: Aron Novak commented 18 August 2009 at 10:41

Priority:

Normal

» Critical

If this issue is valid in mapper 2.x also, this should be clarified and fixed before FeedAPI mapper 2.0 beta 1

Comment #15

Aron Novak

Hungarian

Hungary, Budapest

CreditAttribution: Aron Novak commented 19 August 2009 at 10:32

Title:	date_modify() expects parameter 1 to be DateTime, boolean given	» timestamp mapping: date_modify() expects parameter 1 to be DateTime, boolean given
Version:	6.x-1.x-dev	» 6.x-2.x-dev
Status:	Needs work	» Reviewed & tested by the community

I rerolled the patch against 2.x, but it also applies to 1.x with fuzz.
I'd say let's treat the other issues separated. I'd say this single patch is RTBC now.
I'll surely find and fix other problems about date mapping while working on #552480: More extensive tests in feedapi_mapper_date.test