|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64991 php intl v3 test case failures with icu 51-2
Submitted: 2013-06-08 04:00 UTC Modified: 2021-01-17 04:22 UTC
From: jithin1987 at gmail dot com Assigned: cmb (profile)
Status: No Feedback Package: intl (PECL)
PHP Version: 5.3.26 OS: redhat 6
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:
Bug Type:
From: jithin1987 at gmail dot com
New email:
PHP Version: OS:


 [2013-06-08 04:00 UTC] jithin1987 at gmail dot com
When using php intl v3 stable with icu 51-2 and php-5.3.24 I am seeing 12 community test case failures. 

Test script:
php -dopen_basedir= /lib/php22/build/run-tests.php -q --show-diff -s all.txt
These are test cases which are bundled with the php intl release.

These test cases pass with icu 4.2 which I was using before.

Expected result:
I expected all the 388 test cases to pass.

Actual result:
Actual results are captured in the output of the phpt results here

Failed test cases are :

Bug #58756: w.r.t MessageFormatter [tests/bug58756_MessageFormatter.phpt]
asort() [tests/collator_asort.phpt]
compare() [tests/collator_compare.phpt]
collator_get_sort_key() [tests/collator_get_sort_key.phpt]
sort() [tests/collator_sort.phpt]
sort_with_sort_keys() [tests/collator_sort_with_sort_keys.phpt]
IntlDateFormatter::formatObject(): IntlCalendar tests [tests/dateformat_formatObject_calendar.phpt]
IntlDateFormatter::formatObject(): DateTime tests [tests/dateformat_formatObject_datetime.phpt]
datefmt_format_code() (5.3+, ICU >= 50) [tests/dateformat_format_50+.phpt]
datefmt_format_code() and datefmt_parse_code() (ICU >= 50) [tests/dateformat_format_parse_50+.phpt]
MessageFormat accepts IntlCalendar args [tests/msgfmt_format_intlcalendar.phpt]
IntlTimeZone::getDisplayName(): type parameter (ICU >= 49) [tests/timezone_getDisplayName_variant2-49+.phpt]


fix-test-cases (last revision 2013-06-21 13:28 UTC by jithin1987 at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-10 08:06 UTC]
-Status: Open +Status: Feedback
 [2013-06-10 08:06 UTC]
Those are almost the test fails due to the changed output of the ICU. Many of that 
tests are fixed in PHP 5.4 and above.

In the mood to fix that tests? Look what the others do with checking the ICU 

 [2013-06-10 09:22 UTC] jithin1987 at gmail dot com
-Status: Feedback +Status: Open
 [2013-06-10 09:22 UTC] jithin1987 at gmail dot com
Hi ab,

When you say the tests are fixed with php 5.4 does that mean some changes with php itself or is it all about the php/ext/intl code base? I built php intl from . Does your comment means I shouldn't be building intl from pecl release?
 [2013-06-10 09:53 UTC]
-Status: Open +Status: Feedback
 [2013-06-10 09:53 UTC]
It shouldn't matter whether PECL or the core version is used. What really matters 
is the ICU version. As ICU moves forward, several things like timezone names, 
date/time/whatever representation strings, etc. might slightly change. Therefore 
after exchanging the ICU version some tests could to fail. That aren't really bugs 
but "test bugs", because the --EXPECT-- section isn't synchronized with the given 
ICU version. So again, that's really about fixing the tests, not the code behind 
 [2013-06-10 10:06 UTC]
Ah, I think I gave not quite correct info. ICU 51 is very new, I dont think no 
tests was ever fixed for that version, the latest it was synced with is 50.1.2, as 
far as i can see. Thus the tests might in all probability fail with 51.
 [2013-06-10 10:07 UTC]
I don't think the tests was fixed for 51 I mean )
 [2013-06-11 10:43 UTC]
-Status: Feedback +Status: Verified
 [2013-06-17 10:43 UTC] jithin1987 at gmail dot com
I was looking into each test case failures and checking if I can tie it up with some icu/cldr changes. One change in CLDR wrt sorting I found is the change in sort order by putting native scripts before latin.

However the failure in test case tests/collator_asort.phpt is for a case where latin characters are sorted in ru_RU locale.

Input :
  array( '1' => 'п',
         '4' => '',
         '7' => 'd',
         '2' => 'пп' )
Desired  :
array (
  4 => '',
  7 => 'd',
  1 => 'п',
  2 => 'пп',)

Actual :
     [4] =>
     [1] => п
     [2] => пп
     [7] => d

Here I believe that the actual output given by intl extension for collator_asort() is incorrect and desired output is the Actual one.
I modified one of the icu collator examples to compare n & d in ru_RU locale and it correctly identifies n as greater than d. I have captured it here - 
Can someone please check if I have done it correctly?

I am not sure on why this discrepancy in intl output and I am not sure if this is merely because of data set changes.
 [2013-06-19 09:57 UTC] jithin1987 at gmail dot com
I have reported a separate but regarding the collator_asort/sort sorting issue 
since it's  not related to data set changes and I believe it needs to be handled 
 [2013-06-21 13:29 UTC] jithin1987 at gmail dot com
I have added a patch which addresses the reported test case failures with icu 51. 
Please take a look.
 [2013-07-02 16:07 UTC] jithin1987 at gmail dot com
Can someone please review my patch and see if it can be accepted?
 [2013-07-21 13:13 UTC]
-Assigned To: +Assigned To: cataphract
 [2014-02-17 14:11 UTC] weirdan at gmail dot com
@ jithin1987 at gmail dot com
That's not 'n' (LATIN SMALL LETTER N U+006E), that's a Cyrillic 'п' (CYRILLIC SMALL LETTER PE U+043F). Looks similar, but it's a different letter.
 [2017-10-24 05:45 UTC]
-Status: Verified +Status: Assigned
 [2021-01-07 13:25 UTC]
-Status: Assigned +Status: Feedback -Assigned To: cataphract +Assigned To: cmb
 [2021-01-07 13:25 UTC]
I assume that this is no longer relevant, or is it?
 [2021-01-17 04:22 UTC] pecl-dev at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Mon Dec 04 20:01:27 2023 UTC