Answers.Body: <p>Sounds like you are running into the <a href="https://en.wikipedia.org/wiki/Year_2038_problem" rel="nofollow noreferrer">Year 2038 problem</a>. </p>
  
  <p>You have different behavior on different machines, which makes sense, and also probably will make this problem easier for you to troubleshoot. <em>(I couldn't reproduce the error message in my environment, which makes this tricky to diagnose.)</em></p>
  
  <p>I'm not positive what the <em>exact</em> culprit is for you, but here are some guesses...</p>
  
  <h2>Different architecture</h2>
  
  <p>I <em>think</em> the most likely explanation for your different behavior is <em>different architecture</em>. </p>
  
  <p>Assuming both machines are unix-based, you can run <code>uname -i</code> to see your system architecture on each. </p>
  
  <ul>
  <li>A result of <code>x86_64</code> means you are running a 64 bit system (good)</li>
  <li>A result of <code>i386</code> (or similar) means you are running a 32 bit system (bad)</li>
  </ul>
  
  <p>If your dev box shows <code>x86_64</code> and your production server shows <code>i386</code>, I would guess that upgrading your server to a 64 bit OS would solve this problem.</p>
  
  <h2>Different software</h2>
  
  <p>I think it's also <em>possible</em> that your two systems have the <em>same</em> architecture, but some difference in <em>system software</em> that would lead to this problem, since many software projects are still in the process of mitigating against Y2k38.</p>
  
  <p>I recommend comparing the versions of MySQL and PHP running on each machine and troubleshooting from there.</p>
  
  <p><strong>Please post a comment when you figure out what the culprit was for you!</strong></p>
  
  <h2>Other notes</h2>
  
  <ul>
  <li>Again, I'm not certain what <em>exactly</em> is causing this problem, but I would say it's very unlikely to be an issue within CiviCRM.</li>
  <li>Even for custom fields, CiviCRM stores dates as a <code>DATETIME</code> data type in MySQL which will continue to work until we hit the <a href="https://en.wikipedia.org/wiki/Year_10,000_problem" rel="nofollow noreferrer">Y10k problem</a>. </li>
  <li>MySQL still has some Y2k38-related problems, like <a href="https://bugs.mysql.com/bug.php?id=12654" rel="nofollow noreferrer">this one</a>, but based on the fact that you and I are both able to use large dates on our dev boxes, I'm guessing your're not running into that</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-22T21:46:07.110Z
Answers.Text: Yes, this must be it, thank you!  From what it looks like, I have a 64bit machine, but all the software (php, mysql, etc) is 32bit - and I bet that's what is causing the issue.  We're on an older Linode VPS that, at one point, was switched over from a 32bit kernel to 64bit. It looks like it just upgraded the kernel, not the software.  I didn't even realize that until you mentioned the year 2038 problem, thanks!  Time to figure out how to resolve this (guessing I have to fire up a new Linode box and move everything as I don't think it's that easy to upgrade the apps to 64bit).
Answers.UserDisplayName: Paul B
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-22T19:33:46.143Z
Answers.LastActivityDate: 2017-04-22T19:33:46.143Z
Answers.UserDisplayName: Sean
Body: <p>Using the API, I try to create a contribution record.  One of my custom fields is a date field.  If I set the date to more than 20 years or so past the current date, I get the following error:</p>
  
  <blockquote>
    <p>[error_message] => custom_154 is not a valid date: 2038-01-19 08:00</p>
  </blockquote>
  
  <p>If I lower this date by one month, even by one day, using the same format, it works fine.  One day past the 19th, it fails.</p>
  
  <p>What's odd is that any date I put in, even 100 years out, works great on my dev box.  This is only happening on our production site.  And my dev box was a copy of production's DB and files (same Civi version, etc).  So I'm not sure what might be causing this.</p>
  
  <p>I have modified the custom field and set the "Dates may be up to" to 100 years, but that doesn't help (tried other numbers as well, no use).</p>
  
  <p>Is there some environmental or PHP setting that is causing this?</p>
  
Tags: <custom-fields><api>
Title: Invalid Date with Contribution API and Custom Date Field
ThreadText: # Invalid Date with Contribution API and Custom Date Field
  
  (Asked by: username_0 on 2017-04-22)
  
  Using the API, I try to create a contribution record. One of my custom fields is a date field. If I set the date to more than 20 years or so past the current date, I get the following error:
  
  > [error\_message] => custom\_154 is not a valid date: 2038-01-19 08:00
  
  If I lower this date by one month, even by one day, using the same format, it works fine. One day past the 19th, it fails.
  
  What's odd is that any date I put in, even 100 years out, works great on my dev box. This is only happening on our production site. And my dev box was a copy of production's DB and files (same Civi version, etc). So I'm not sure what might be causing this.
  
  I have modified the custom field and set the "Dates may be up to" to 100 years, but that doesn't help (tried other numbers as well, no use).
  
  Is there some environmental or PHP setting that is causing this?
  
  **Tags:** custom-fields, api
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-04-22. Score: 3 | Accepted answer
  
  Sounds like you are running into the [Year 2038 problem](https://en.wikipedia.org/wiki/Year_2038_problem).
  
  You have different behavior on different machines, which makes sense, and also probably will make this problem easier for you to troubleshoot. *(I couldn't reproduce the error message in my environment, which makes this tricky to diagnose.)*
  
  I'm not positive what the *exact* culprit is for you, but here are some guesses...
  
  ## Different architecture
  
  I *think* the most likely explanation for your different behavior is *different architecture*.
  
  Assuming both machines are unix-based, you can run `uname -i` to see your system architecture on each.
  
  * A result of `x86_64` means you are running a 64 bit system (good)
  * A result of `i386` (or similar) means you are running a 32 bit system (bad)
  
  If your dev box shows `x86_64` and your production server shows `i386`, I would guess that upgrading your server to a 64 bit OS would solve this problem.
  
  ## Different software
  
  I think it's also *possible* that your two systems have the *same* architecture, but some difference in *system software* that would lead to this problem, since many software projects are still in the process of mitigating against Y2k38.
  
  I recommend comparing the versions of MySQL and PHP running on each machine and troubleshooting from there.
  
  **Please post a comment when you figure out what the culprit was for you!**
  
  ## Other notes
  
  * Again, I'm not certain what *exactly* is causing this problem, but I would say it's very unlikely to be an issue within CiviCRM.
  * Even for custom fields, CiviCRM stores dates as a `DATETIME` data type in MySQL which will continue to work until we hit the [Y10k problem](https://en.wikipedia.org/wiki/Year_10,000_problem).
  * MySQL still has some Y2k38-related problems, like [this one](https://bugs.mysql.com/bug.php?id=12654), but based on the fact that you and I are both able to use large dates on our dev boxes, I'm guessing your're not running into that
  
  > **Comments:**
  > **username_0**: Yes, this must be it, thank you!  From what it looks like, I have a 64bit machine, but all the software (php, mysql, etc) is 32bit - and I bet that's what is causing the issue.  We're on an older Linode VPS that, at one point, was switched over from a 32bit kernel to 64bit. It looks like it just upgraded the kernel, not the software.  I didn't even realize that until you mentioned the year 2038 problem, thanks!  Time to figure out how to resolve this (guessing I have to fire up a new Linode box and move everything as I don't think it's that easy to upgrade the apps to 64bit).  
  
  ---
  
  