Magento 2.4.8-p3 & PHP 8.4: Unraveling the Critical Date Parsing Bug with IntlDateFormatter

In the fast-paced world of e-commerce, data accuracy is paramount. Every timestamp, every order date, and every delivery schedule must be precise to ensure smooth operations and customer satisfaction. However, a critical bug has emerged 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, related to the IntlDateFormatter::parse() function, can lead to completely erroneous dates being returned, turning a simple '2026-02-10 10:49:38' into a baffling '2015-08-19 10:49:00'. As experts in Magento migrations and development at Shopping Mover, we're here to break down this significant challenge and guide you through its implications and solutions.

The Critical Date Parsing Bug Explained

The heart of this problem lies within how Magento 2.4.8-p3, when paired with PHP 8.4, handles date parsing. The IntlDateFormatter::parse() function, a standard PHP class for locale-aware date and time formatting, is misinterpreting valid ISO datetime strings (YYYY-MM-DD HH:MM:SS). Instead of accurately converting these strings into their corresponding timestamps, it produces wildly incorrect results.

This bug was first reported on GitHub (Issue #40524) by a vigilant developer who noticed discrepancies when using the GraphQL API to retrieve order details. Specifically, the order_date field, which is crucial for tracking and reporting, was displaying incorrect information. This isn't just a minor display glitch; it represents a fundamental breakdown in data integrity.

Impact on Magento Stores and Migrations

For any Magento store, the implications of incorrect date parsing are severe and far-reaching:

• Data Integrity Issues: At the core, this bug corrupts fundamental sales data. Incorrect order dates can skew sales reports, invalidate customer purchase histories, and throw off inventory tracking, leading to poor business decisions.
• Customer Experience Degradation: Imagine a customer checking their order history only to see an order placed years in the past or future. This leads to confusion, distrust, and an inevitable surge in support inquiries, damaging your brand reputation.
• Operational Disruptions: Most e-commerce operations rely heavily on accurate timestamps. Third-party integrations for shipping, accounting, CRM, or marketing automation systems that pull order data from Magento's core will receive and process incorrect dates. This can lead to delayed shipments, incorrect billing, mis-targeted campaigns, and a cascade of operational failures.
• Migration and Upgrade Hurdles: For businesses planning a Magento migration or a crucial PHP upgrade to 8.4, 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, turning a smooth transition into a crisis. At Shopping Mover, we frequently encounter such nuanced challenges during platform transitions, emphasizing the need for expert oversight.

Technical Deep Dive: Unraveling the Root Cause

The core of the problem, as identified in the GitHub issue, lies within Magento's lib/internal/Magento/Framework/Stdlib/DateTime/Timezone.php (around line 199). Magento creates an IntlDateFormatter instance using \IntlDateFormatter::SHORT for both date and time formats, without explicitly defining a pattern:

$formatter = new \IntlDateFormatter(
    $locale,
    \IntlDateFormatter::SHORT,
    \IntlDateFormatter::SHORT,
    $timezone
);

$timestamp = $formatter->parse($date);

However, the input string being parsed (e.g., '2026-02-10 10:49:38') is in a standard ISO format (yyyy-MM-dd HH:mm:ss), which does not inherently match the locale-dependent SHORT format.

With PHP 8.4 (and likely due to underlying changes in the ICU library that PHP's Intl extension relies upon), this mismatch in format handling has changed behavior. Previously, such a mismatch might have resulted in a parsing failure or a more predictable error. Now, it results in an incorrect but valid timestamp, making the bug much harder to detect without explicit testing.

The issue was traced back to a specific commit (85ad2c2b2e414557f4d091d113c244b40c55d885) that altered how order_date was handled in the GraphQL API, moving from directly using getCreatedAt() to formatting it via timezone->date()->format(), which then feeds into the problematic IntlDateFormatter logic.

Identifying if Your Store is Affected

To determine if your Magento store is vulnerable, check the following:

• Magento Version: Are you running Magento Open Source or Adobe Commerce 2.4.8-p3?
• PHP Version: Is your server environment using PHP 8.4 or higher? (Note: The issue might also manifest with specific ICU library versions even on slightly older PHP, as noted in the GitHub comments).
• Functionality: Do you rely on the GraphQL API for order data? Do you have custom modules or integrations that parse dates using Magento's Timezone helper or IntlDateFormatter directly with SHORT formats and ISO input?

A simple test, as provided in the GitHub issue, can confirm the behavior:

$formatter = new \IntlDateFormatter(
    'de_DE', // Or your store's locale
    \IntlDateFormatter::SHORT,
    \IntlDateFormatter::SHORT,
    'UTC'
);

$timestamp = $formatter->parse('2026-02-10 10:49:38');
var_dump(date('Y-m-d H:i:s', $timestamp));
// Expected: 2026-02-10 10:49:38
// Actual (bugged): 2015-08-19 10:49:00 (or similar incorrect date)

Solutions and Workarounds

While Magento's core team is actively working on a permanent fix (the issue is confirmed and being addressed), several immediate actions can be taken:

• Temporary Patch/Revert: The original reporter provided a temporary patch for the GraphQL API context by reverting the problematic change in Model/Formatter/Order.php. This involves changing:

  -            'order_date' => $this->timezone->date($orderModel->getCreatedAt())
  -                ->format(DateTime::DATETIME_PHP_FORMAT),
  +            'order_date' => $orderModel->getCreatedAt(),
          

  This bypasses the problematic formatting for the order_date in GraphQL. However, this is a specific workaround for one instance and may not cover all affected areas.
• Explicit Pattern Definition: The most robust long-term solution involves explicitly defining the date pattern for IntlDateFormatter to match the input string. For ISO strings like YYYY-MM-DD HH:MM:SS, you would use a pattern like 'yyyy-MM-dd HH:mm:ss'. This ensures the formatter knows exactly what to expect.
• Stay Updated: Keep a close eye on official Magento releases and patches. Adobe Commerce and Magento Open Source will undoubtedly release a fix for this critical issue in an upcoming patch release. Ensure your Composer dependencies are regularly updated.
• Thorough Testing: Before any major PHP or Magento upgrade, always conduct comprehensive regression testing, especially focusing on date-sensitive functionalities like order processing, reporting, and integrations.

Shopping Mover: Your Partner in Magento Development & Migration

At Shopping Mover (shopping-mover.com), we specialize in navigating the complexities of Magento development, upgrades, and migrations. Issues like the IntlDateFormatter bug highlight the intricate challenges that can arise when evolving your e-commerce platform. Our team of Magento migration experts is equipped to:

• Audit Your Current Setup: Identify vulnerabilities and compatibility issues before they impact your business.
• Implement Robust Solutions: Apply necessary patches, develop custom fixes, and ensure your date handling is flawless across your Magento instance.
• Ensure Seamless Migrations: Plan and execute your Magento 2 migrations or PHP upgrades with meticulous attention to detail, preventing data integrity issues and operational disruptions.

Don't let critical bugs derail your e-commerce success. Partner with Shopping Mover to ensure your Magento store runs flawlessly, now and into the future.

Conclusion

The IntlDateFormatter bug in Magento 2.4.8-p3 with PHP 8.4 is a stark reminder of the continuous vigilance required in e-commerce platform management. While the Magento community and core team are working diligently on a fix, understanding the problem and implementing temporary solutions is crucial for maintaining data integrity and customer trust. By staying informed and leveraging expert assistance, you can safeguard your store against such unforeseen challenges and ensure a robust, reliable e-commerce experience.