php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #78432 IntlDateFormatter not parsing from given format for some locales
Submitted: 2019-08-21 07:53 UTC Modified: 2019-08-21 14:49 UTC
From: justmoen at gmail dot com Assigned:
Status: Not a bug Package: intl (PECL)
PHP Version: 7.2.21 OS: Ubuntu 16.04
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: justmoen at gmail dot com
New email:
PHP Version: OS:

 

 [2019-08-21 07:53 UTC] justmoen at gmail dot com 
Description:
------------
IntlDateFormatter appears to treat the provided pattern parameter 'MM/dd/yyyy h:mm: a' as invalid based on the given culture.  The problem occurs after a change in ICU 64.1 to no longer accept am/pm for cultures with the languages 'es', 'sv' and several others. 

Should the IntlDateFormatter be able to parse from a standard pattern independent of the set locale?

Test script:
---------------
<?php
$date = '08/08/2019 06:00 pm';
$cultureZones = [
'en_US' => 'US/Central',
'es_US' => 'US/Central',
'fr_CA' => 'Canada/Central',
'en_CA' => 'Canada/Central',
'es_ES' => 'Europe/Madrid',
'en_GB' => 'Europe/London',
'es_MX' => 'America/Mexico_City',
'fr_FR' => 'Europe/Paris',
'sv_SE' => 'Europe/Stockholm'
];
foreach($cultureZones as $culture => $timezone) {
$formatter = new \IntlDateFormatter($culture, 2, 2, $timezone, 1, 'MM/dd/yyyy h:mm a');
echo $culture." (".$timezone.") returned: ".var_export( $formatter->parse($date), true )."\n";
}

Expected result:
----------------
en_US (US/Central) returned: 1565305200
es_US (US/Central) returned: 1565305200
fr_CA (Canada/Central) returned: 1565305200
en_CA (Canada/Central) returned: 1565305200
es_ES (Europe/Madrid) returned: 1565280000
en_GB (Europe/London) returned: 1565283600
es_MX (America/Mexico_City) returned: 1565305200
fr_FR (Europe/Paris) returned: 1565280000
sv_SE (Europe/Stockholm) returned: 1565280000

Actual result:
--------------
en_US (US/Central) returned: 1565305200
es_US (US/Central) returned: false
fr_CA (Canada/Central) returned: 1565305200
en_CA (Canada/Central) returned: 1565305200
es_ES (Europe/Madrid) returned: false
en_GB (Europe/London) returned: 1565283600
es_MX (America/Mexico_City) returned: false
fr_FR (Europe/Paris) returned: 1565280000
sv_SE (Europe/Stockholm) returned: false

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-08-21 08:10 UTC] justmoen at gmail dot com
-Summary: IntlDateFormatter not parsing from given format +Summary: IntlDateFormatter not parsing from given format for some locales
 [2019-08-21 08:10 UTC] justmoen at gmail dot com 
update summary
 [2019-08-21 13:25 UTC] requinix@php.net
-Status: Open +Status: Not a bug -Package: Date/time related +Package: intl
 [2019-08-21 13:25 UTC] requinix@php.net 
> Should the IntlDateFormatter be able to parse from a standard pattern independent of the set locale?
I would say no, but regardless this is something you would have to request of the ICU project - not PHP. We merely provide a wrapper around their library.

Note that if you're parsing date strings in the "MM/dd/yyyy h:mm a" (aka "m/d/Y H:i a") format then you can, and probably should, skip IntlDateFormatter::parse() and use regular old strtotime/DateTime instead. The intl stuff handles locale differences, and if you don't need or want locale handling...
 [2019-08-21 14:49 UTC] justmoen at gmail dot com 
In this case, it is a framework that is calling the IntlDateFormatter for the reverse transform operation.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Oct 27 01:00:02 2025 UTC