1

When trying to run the Contributions Summary report I get the following message:

DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character

Tried standards tricks, checking file permissions, clearing caches unable to resolve the issue.

$Fatal Error Details = Array
(
    [message] => DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
    [code] => 
    [exception] => Exception Object
        (
            [message:protected] => DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
            [string:Exception:private] => 
            [code:protected] => 0
            [file:protected] => /var/www/example.com/sites/all/modules/civicrm/CRM/Report/Form/Contribute/Summary.php
            [line:protected] => 745
            [trace:Exception:private] => Array
  • Can you check the data format you are using in CiviCRM and the data of the contribution that is the problem (if you can find it)? – ErikH - CiviCooP Jan 28 '16 at 15:35
1

It seems like you have some invalid data in your database. I don't think this is related to file permissions or caches. Is it possible that you imported data via a SQL command rather than the UI or API?

Try turning on the backtrace function in Administer menu > CiviCRM > Debugging and Error Handling, and hopefully you'll get a better sense of which field this is supposed to be. Alternatively, look at the fields that are likely to be called in your instance of the report - checking columns, filters, etc. - and then run SQL commands to find a datetime field with a value of "201401".

Since this is likely to be in civicrm_contribution, I looked up the datetime fields in that table. There are four. Try running these commands, then see how this data get entered?

SELECT id, contact_id, receive_date FROM civicrm_contribution WHERE receive_date = '201401';
SELECT id, contact_id, receipt_date FROM civicrm_contribution WHERE receipt_date = '201401';
SELECT id, contact_id, cancel_date FROM civicrm_contribution WHERE cancel_date = '201401';
SELECT id, contact_id, thankyou_date FROM civicrm_contribution WHERE thankyou_date = '201401';

UPDATE: That backtrace is super-helpful! I looked at the code in CRM/Form/Contribute/Summary.php and I see better what's happening here. The issue is still invalid data - just not in the format I expected.

This part of the code is the part that creates the links on the Summary Report to drill-down links. See the links in the screenshot: enter image description here

So Civi is converting the start dates of each of those months into a different format. One of your contributions still seems to be happening in a different month.

  • You can try commenting out lines 737-786 of the file I mentioned - you'll lose the drill-down links, but hopefully the invalid data doesn't affect anything else.
  • This bug shouldn't trigger unless you're grouping by receive date.
  • You can try tracking down that bad data. Try this SQL:

    SELECT id, contact_id, receive_date FROM civicrm_contribution ORDER BY receive_date; SELECT id, contact_id, receive_date FROM civicrm_contribution ORDER BY receive_date DESC;

Check the bottom of both those lists for odd-looking receive_dates, my guess is you'll find one!

  • 1
    Hi Jon, big thanks for your advice. Data has been moved from a debian 6 server and moved to a debian 7 server, so I did use mysqldump to take over data but this was a carbon copy. Database was then upgrade from 4.4 -> 4.5 -> 4.6. I have checked the contributions table, the only times present are for receive_date and its formatted as "2000-06-08 00:00:00", Can't see any data equalling '2010401'. Paste binned the main backtrace here; pastebin.com/ZuE0zyGf Summary.php line 475: $endDate = new DateTime($dateStart); – fyberoptik Feb 2 '16 at 16:27
  • I just updated my answer - the backtrace was very helpful! – Jon G - Megaphone Tech Feb 3 '16 at 17:43
  • Jon, you're a damn genius. I ran the SQL commands and sure enough I found some very odd date formats that weren't consistent with the rest of the data. Thanks again for your help. – fyberoptik Feb 9 '16 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.