Y2K38 Bug - Code adapt or Server Config

So after reading the article regarding the Y2K38 bug, I rounded up our dev team to discuss the way forward.

One of our clients are a financial institution, so as you can guess, their dates will soonthe maximum date that strtotime() and date can handle on a 32bit PHP.

Here are the takes:
My suggestion was to alter the code. Since we have a date class encapsulating all date functions, it will be a single file to change.

One of the other senior developers simply threw his hands in the air and asked why we should worry about this, a 64 bit OS with 64bit PHP has problem handled.

So, if we do not change our code, but rather rely on the server, what happens if we have hardware failure and are forced to move the code to one of our other servers running 32 bit OS and PHP?

To me, I do not see why we should rely on hardware. PHP code should be independent of platform.

Sounds like you should be thinking about upgrading to a 64 bit OS then.

Best of luck convincing your senior programmer. Remind him/her that a little effort now could prevent significant problems later!

@logic_earth: Truth be told, I prefer Zend Framework above our framework. I would any time use Zend Date, but how do I go about convincing the other developers to use it.

The current framework is focused on a basic set of rules. It does not have a MVC pattern implemented and is difficult to read. It takes up way to much overhead. But hey, Im trying my best to change a few things.

If your code is easy to fix, test and deploy, that’s a good enough reason to change it. It’s especially vital if your clients can choose their own hosting platform.

Even if you handling the hosting, your senior programmer cannot possibly know the future direction of your company. The code may packaged for resellers or sold as an installable product. Some of the classes may be reused in other products.

You could spend days arguing the pros and cons, but I’d suggest you spend that time fixing the issue.

I personally instead of reinventing the wheel would just use Zend Date.

I agree. Fixing the code eliminates any external factor and puts the control back in our hands.

Since we do not have our own server, we can not possibly decide the configuration of it.

True, but currently we are running n a 32bit OS and already we are very close to using dates beond 2038…

The problem only exists for 32 bit operating systems so the first question should be “do you expect this to still be running on a 32 bit operating system when dates after that are needed?”.

The simplest fix is to upgrade the server you are running it on to a 64 bit operating system.