Prevent 2038 issue in Magento

Hello, Amasty blog readers!

Today I’m offering you a free small tool for preventing a 2038 problem on Magento 2.

2038 problem and how it reveals itself on Magento 2

Do you know what will happen on  after 03:14:07 UTC on 19 January 2038?

The time beyond that will wrap around and be stored internally as a negative number, which these systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038. This problem is similar to the Millennium Bug.

Of course, by that time all the servers will be upgraded to avoid the issue, but let’s see how this problem may affect your time sensitive settings in Magento 2.

If you accidentally choose the longest valid period possible for a coupon, it won’t work. This issue is also present on Magento 1, but it’s easier to choose the max period in Magento 2 thanks to the interface:

How to prevent 2038 problem in Magento 2

Now, the coupon stops working because Magento, as all other platforms working on MySQl, can’t accept and store dates after 2038 in the timestamp fields.

If we set a date later than 2038 year, it just slips to 1970 year, leaving us with an invalid coupon or any other feature that uses the timestamp fields.

To avoid this issue, I implemented an extension, which helps to avoid such accidents. In the future, such fixes won’t be needed as the issue will be solved on a server level.

The extension simply makes it impossible to choose any dates after 2037 year in your Magento 2. Technically, this is not a fix, but it’s a workaround to avoid accidental issues with all the Magento 2 features that are using dates. Instead of explaining the issue to all the store managers, you can simply install this extension and be sure everything works.

Feel free to download the extension below or to share it with your fellow Magento 2 users and developers.


Will be happy to answer any questions in the comments!