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] =&gt; DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
      [code] =&gt; 
      [exception] =&gt; Exception Object
          (
              [message:protected] =&gt; DateTime::__construct(): Failed to parse time string (2010401) at position 6 (1): Unexpected character
              [string:Exception:private] =&gt; 
              [code:protected] =&gt; 0
              [file:protected] =&gt; /var/www/example.com/sites/all/modules/civicrm/CRM/Report/Form/Contribute/Summary.php
              [line:protected] =&gt; 745
              [trace:Exception:private] =&gt; 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:
  [![enter image description here](https://i.sstatic.net/yrsPr.jpg)](https://i.sstatic.net/yrsPr.jpg)
  
  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.  
  
  ---
  
  