php.net |  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: 2017-10-24 05:45 UTC
From: jithin1987 at gmail dot com Assigned: cataphract (profile)
Status: Assigned 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:
Package:
Bug Type:
Summary:
From: jithin1987 at gmail dot com
New email:
PHP Version: OS:

 

 [2013-06-08 04:00 UTC] jithin1987 at gmail dot com
Description:
------------
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 https://www.dropbox.com/s/2b9wi7hd8ii8mho/php%20intl%203.txt

Failed test cases are :

FAILED TEST SUMMARY
---------------------------------------------------------------------
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]

Patches

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

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-10 08:06 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2013-06-10 08:06 UTC] ab@php.net
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 
version.

Thanks
 [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 http://pecl.php.net/package/intl . Does your comment means I shouldn't be building intl from pecl release?
 [2013-06-10 09:53 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2013-06-10 09:53 UTC] ab@php.net
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 
it.
 [2013-06-10 10:06 UTC] ab@php.net
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] ab@php.net
I don't think the tests was fixed for 51 I mean )
 [2013-06-11 10:43 UTC] ab@php.net
-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.

http://unicode.org/cldr/trac/ticket/4020
http://unicode.org/cldr/trac/ticket/5577

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 :
Array
 (
     [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 - https://github.com/jithin1987/intl/blob/master/icu/test_ru_sort.cpp 
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 
differently.

https://bugs.php.net/bug.php?id=65061
 [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] cataphract@php.net
-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] kalle@php.net
-Status: Verified +Status: Assigned
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Sep 18 09:01:27 2019 UTC