Invalid Date with Contribution API and Custom Date Field

Question

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?

Answer 1

Sounds like you are running into the 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.
• MySQL still has some Y2k38-related problems, like this one, 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