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

go to bug id or search bugs for

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 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: 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)

Pull Requests

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
 [2021-01-07 13:25 UTC] cmb@php.net
-Status: Assigned +Status: Feedback -Assigned To: cataphract +Assigned To: cmb
 [2021-01-07 13:25 UTC] cmb@php.net 
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-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC