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...
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.
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!
- 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