Skip to content

IntlDateFormatter::parse() misparses ISO datetime string in PHP 8.4 (returns incorrect date) #40524

@marvincaspar

Description

@marvincaspar

Preconditions and environment

  • Magento version 2.4.8-p3
  • PHP 8.4

Steps to reproduce

  • Use PHP 8.4
  • Use a locale such as de_DE (or other non-ISO locale)
  • Call:
$formatter = new \IntlDateFormatter(
    'de_DE',
    \IntlDateFormatter::SHORT,
    \IntlDateFormatter::SHORT,
    'UTC'
);

$timestamp = $formatter->parse('2026-02-10 10:49:38');
var_dump(date('Y-m-d H:i:s', $timestamp));
  • Observe incorrect parsed date.

Expected result

2026-02-10 10:49:38

Actual result

2015-08-19 10:49:00

Additional information

I noticed this bug when using the graphql api to get orders (

'order_date' => $this->timezone->date($orderModel->getCreatedAt())
). In Magento 2.4.7 it works fine. This is the commit which causes the issue 85ad2c2


When running Magento 2 with PHP 8.4, IntlDateFormatter::parse() produces an incorrect timestamp when parsing a valid ISO datetime string (YYYY-MM-DD HH:MM:SS).

Specifically, parsing the string:

2026-02-10 10:49:38

results in a completely incorrect date (e.g. 2015-08-19 10:49:00) instead of the expected 2026-02-10 10:49:38.

The issue appears to originate from this code in:

lib/internal/Magento/Framework/Stdlib/DateTime/Timezone.php (around line 199)

$date = $formatter->parse($date) ?: (new \DateTime($date))->getTimestamp();

Magento creates an IntlDateFormatter using SHORT date/time formats without defining an explicit pattern:

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

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

However, the input string is in ISO format (yyyy-MM-dd HH:mm:ss), which does not match the locale-dependent SHORT format.

With PHP 8.4 (likely due to ICU changes), this now results in incorrect but valid timestamps instead of failing cleanly.

Workaround

To fix is quickly I reverted the commit with this patch

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(),
             'order_number' => $orderModel->getIncrementId(),
             'status' => $orderModel->getStatusLabel(),
             'email' => $orderModel->getCustomerEmail(),

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

Metadata

Metadata

Assignees

Labels

Area: OrderComponent: SalesIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P2A defect with this priority could have functionality issues which are not to expectations.Reported on 2.4.8-p3Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchTriage: Dev.ExperienceIssue related to Developer Experience and needs help with Triage to Confirm or Reject it

Type

No type

Projects

Status

Ready for Development

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions