Answers.Body: <p>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?</p>
  
  <p>Try turning on the backtrace function in <strong>Administer menu > CiviCRM > Debugging and Error Handling</strong>, 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".</p>
  
  <p>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?</p>
  
  <pre><code>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';
  </code></pre>
  
  <p>UPDATE: That backtrace is super-helpful!  I looked at the code in <code>CRM/Form/Contribute/Summary.php</code> and I see better what's happening here. The issue is still invalid data - just not in the format I expected.</p>
  
  <p>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:
  <a href="https://i.sstatic.net/yrsPr.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/yrsPr.jpg" alt="enter image description here"></a></p>
  
  <p>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.</p>
  
  <ul>
  <li>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.</li>
  <li>This bug shouldn't trigger unless you're grouping by receive date.</li>
  <li><p>You can try tracking down that bad data.  Try this SQL:</p>
  
  <p>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;</p></li>
  </ul>
  
  <p>Check the bottom of both those lists for odd-looking receive_dates, my guess is you'll find one!  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-02T16:27:34.633Z
Answers.Text: 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; http://pastebin.com/ZuE0zyGf 
  Summary.php line 475: $endDate = new DateTime($dateStart);
Answers.UserDisplayName: jamboNum5
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-03T17:43:25.643Z
Answers.Text: I just updated my answer - the backtrace was very helpful!
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-09T12:44:16.463Z
Answers.Text: 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.
Answers.UserDisplayName: jamboNum5
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-29T21:46:50.903Z
Answers.LastActivityDate: 2016-02-09T14:56:19.567Z
Answers.LastEditDate: 2016-02-09T14:56:19.567Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>When trying to run the Contributions Summary report I get the following message:</p>
  
  <pre><code>DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
  </code></pre>
  
  <p>Tried standards tricks, checking file permissions, clearing caches unable to resolve the issue.</p>
  
  <pre><code>$Fatal Error Details = Array
  (
      [message] =&amp;gt; DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
      [code] =&amp;gt; 
      [exception] =&amp;gt; Exception Object
          (
              [message:protected] =&amp;gt; DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
              [string:Exception:private] =&amp;gt; 
              [code:protected] =&amp;gt; 0
              [file:protected] =&amp;gt; /var/www/example.com/sites/all/modules/civicrm/CRM/Report/Form/Contribute/Summary.php
              [line:protected] =&amp;gt; 745
              [trace:Exception:private] =&amp;gt; Array
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-28T15:35:15.603Z
Comments.Text: 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)?
Comments.UserDisplayName: ErikH - CiviCooP
Tags: <civireport>
Title: Error Running Contributions Summary Report
ThreadText: # Error Running Contributions Summary Report
  
  (Asked by: username_0 on 2016-01-28)
  
  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
  
  **Tags:** civireport
  
  > **Comments:**
  > **username_1**: 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)?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2016-01-29. Score: 1 | Accepted answer
  
  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:
  
  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!
  
  > **Comments:**
  > **username_0**: 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; http://pastebin.com/ZuE0zyGf  Summary.php line 475: $endDate = new DateTime($dateStart);  
  > **username_2**: I just updated my answer - the backtrace was very helpful!  
  > **username_0**: 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.  
  
  ---
  
  