Critical Date Misparsing Bug Hits Magento 2.4.8-p3 with PHP 8.4: What You Need to Know for Stable Operations

A critical date parsing bug has been identified in Magento Open Source and Adobe Commerce version 2.4.8-p3, specifically impacting installations running with PHP 8.4 or newer versions of the ICU library. This issue causes the IntlDateFormatter::parse() function to incorrectly interpret standard ISO datetime strings (YYYY-MM-DD HH:MM:SS), leading to completely erroneous dates being returned. For instance, a string representing "2026-02-10 10:49:38" might be parsed and displayed as a drastically different "2015-08-19 10:49:00". This discrepancy can have far-reaching consequences for e-commerce operations.

Impact on Magento Stores and Migrations

This bug primarily affects core Magento functionalities where the IntlDateFormatter is utilized without an explicit pattern. A prime example highlighted in the GitHub issue is the GraphQL API for retrieving order details, where the order_date field could display incorrect information. For merchants, this means:

• Data Integrity Issues: Incorrect order dates can corrupt sales reports, customer history, and inventory tracking.
• Customer Experience Degradation: Customers might see incorrect order placement dates, leading to confusion and support inquiries.
• Operational Disruptions: Any third-party integrations or custom modules relying on accurate date parsing from Magento's core could malfunction, impacting shipping, accounting, or CRM systems.

For businesses undergoing Magento migrations or planning PHP upgrades, this bug presents a significant hurdle. Upgrading to Magento 2.4.8-p3 or migrating to PHP 8.4 without addressing this issue could introduce critical data inconsistencies immediately post-migration.

Technical Deep Dive into the Root Cause

The core of the problem lies within Magento's lib/internal/Magento/Framework/Stdlib/DateTime/Timezone.php file. Here, the IntlDateFormatter is initialized using \IntlDateFormatter::SHORT for both date and time styles, without specifying a custom pattern. While this approach might have been compatible with previous PHP and ICU library versions (e.g., Magento 2.4.7), PHP 8.4 (and likely newer ICU versions) appears to handle this format mismatch differently. Instead of gracefully failing or returning a null value when encountering an ISO-formatted string that doesn't match the SHORT locale format, it now produces an incorrect but seemingly valid timestamp. This change in behavior from PHP/ICU is a key factor.

The issue was specifically traced to a commit introduced between Magento 2.4.7 and 2.4.8, which altered how the order_date is processed within the GraphQL module, exposing this underlying IntlDateFormatter vulnerability.

Reproducibility and Scope

The bug has been officially confirmed as reproducible on Magento 2.4.8-p3 and the 2.4-develop branch, using both PHP 8.4 and 8.5. Community contributors have further clarified that the issue's manifestation is more closely tied to the specific version of the icu package (e.g., version 78.2) installed on the server, rather than being solely dependent on the PHP version itself. This implies a broader potential impact across different PHP environments if the ICU library is updated.

Immediate Workaround for Developers

For developers and system administrators needing an immediate fix, a temporary workaround involves reverting a specific change in the Magento/SalesGraphQl/Model/Formatter/Order.php file. The original reporter provided a patch that effectively bypasses the problematic IntlDateFormatter usage for order_date by directly returning the createdAt timestamp:

diff --git a/Model/Formatter/Order.php b/Model/Formatter/Order.php
index 06afec2ac..409083b6d 100644
--- a/Model/Formatter/Order.php
+++ b/Model/Formatter/Order.php
@@ -48,8 +48,7 @@ class Order
             'id' => base64_encode((string)$orderModel->getEntityId()),
             'increment_id' => $orderModel->getIncrementId(),
             'number' => $orderModel->getIncrementId(),
-            'order_date' => $this->timezone->date($orderModel->getCreatedAt())
-                ->format(DateTime::DATETIME_PHP_FORMAT),
+            'order_date' => $orderModel->getCreatedAt(),
             'status' => $orderModel->getStatusLabel(),
             'email' => $orderModel->getCustomerEmail(),

While this patch offers immediate relief, it is crucial to understand that this is a temporary solution. A proper, comprehensive fix from Magento is anticipated to address the underlying IntlDateFormatter usage across all affected areas.

Recommendations for Magento Users

As an e-commerce migration expert at Shopping Mover, we strongly advise merchants and developers planning upgrades to Magento 2.4.8-p3 or considering PHP 8.4/newer ICU versions to be acutely aware of this bug. It is prudent to either implement the provided workaround during your upgrade process or consider delaying the upgrade until an official patch from Adobe Commerce is released. Keeping a close eye on the official GitHub issue for updates and solutions is highly recommended to ensure the stability and data integrity of your Magento store.