php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 09:01:26 2024 UTC