magento2: Import History Execution Time wrong for other than en_US user locale

Preconditions and environment

• Magento Community version up to 2.4.7-beta2 and 2.4-develop
• fresh install without sample data, on ddev environment
• tested also on version 2.3.7

Steps to reproduce

1. Access admin of vanilla instance, any version (tested from 2.3.7 to 2.4.7-beta2)
2. Change admin user locale to “German (Switzerland)” [de_CH] or “Romanian” [ro_RO] - this can be also done at any point before the Import runs (if vanilla instance with no language packs installed to affect the export)
3. Create a test product
4. System > Export > Products: CSV, Enclose fields > Export > Run Cron > Download CSV
5. System > Import > Products / Behaviour: Add/Update > Check Data > Import
6. System > Import History > Check “Execution Time” column which shows wrong time interval

Expected result

Import History shows correct execution time of the import when import is run by a user with non-en_US locale (de_CH and ro_RO tested)

Actual result

Import History shows incorrect execution time of the import when import is run by a user with non-en_US locale (de_CH and ro_RO tested)

Additional information

Problem appears in the \Magento\Framework\Stdlib\DateTime\Timezone::date method, in the switch branch of case (!is_numeric($date)).

Below is a summarised stack trace with relevant dumps which I’ve performed to track the issue:

IMPORT CSV - en_US locale admin user - CORRECT Execution Time

\Magento\ImportExport\Model\History::setExecutionTime($executionTime = 'Validation') \Magento\ImportExport\Model\History::setExecutionTime($executionTime = 'In Progress') \Magento\Framework\Stdlib\DateTime\Timezone::date($date = ‘2024-01-22 15:42:12’)

• dump $locale: en_US
• dump $timezone: Europe/Berlin
• case (!is_numeric($date)) matched
  • After switch cases before return, obtained timestamp in $date: 1705938132
• dump date('Y-m-d H:i:s', $date): '2024-01-22 15:42:12' \Magento\ImportExport\Helper\Report::getExecutionTime($time = '2024-01-22 15:42:12')
• dump Expected format ($this->timeZone->getDateTimeFormat(\IntlDateFormatter::SHORT)): M/d/yy h:mm a
• dump Diff days ($timeDiff->days): 0
• dump Diff full formatted ($timeDiff->format('%Y-%m-%d %H:%I:%S')): '00-0-0 00:00:04'
• Diff as returned by method ($timeDiff->format('%H:%I:%S')): '00:00:04' \Magento\ImportExport\Model\History::setExecutionTime($executionTime = '00:00:04')

IMPORT CSV - de_CH locale admin user - WRONG Execution Time

\Magento\ImportExport\Model\History::setExecutionTime($executionTime = 'Validation') \Magento\ImportExport\Model\History::setExecutionTime($executionTime = 'In Progress') \Magento\Framework\Stdlib\DateTime\Timezone::date($date = '2024-01-22 15:59:51')

• dump $locale: de_CH
• dump $timezone: Europe/Berlin
• case (!is_numeric($date)) matched
  • After switch cases before return, obtained timestamp in $date: 1815832740 <---- PROBLEM HERE
• dump date('Y-m-d H:i:s', $date): '2027-07-17 13:59:00' \Magento\ImportExport\Helper\Report::getExecutionTime($time = '2027-07-17 13:59:00')
• dump Expected format ($this->timeZone->getDateTimeFormat(\IntlDateFormatter::SHORT)): dd.MM.yy HH:mm
• dump Diff days ($timeDiff->days): 1271,
• dump Diff full formatted ($timeDiff->format('%Y-%m-%d %H:%I:%S')): '03-5-25 22:58:56',
• Diff as returned by method ($timeDiff->format('%H:%I:%S')): '22:58:56' \Magento\ImportExport\Model\History::setExecutionTime($executionTime = '22:58:56')

The execution time might not seem important for user triggered csv imports, but when a custom import is built over the import-export module and imports run as scheduled tasks, import history execution time might be of importance to assess the health of the import, hence the severity can be evaluated even as S2.

In case of a custom import built on top of the import-export module, workaround for getting the correct execution time would be to set locale to en_US before triggering the import methods, but this might affect other data handling in the actually imported data.

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”.