php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74918 Some tests fail for ICU 4.2.1
Submitted: 2017-07-13 11:44 UTC Modified: 2017-07-14 09:21 UTC
From: graefrath at femu dot rwth-aachen dot de Assigned:
Status: Wont fix Package: intl (PECL)
PHP Version: 5.6.31 OS: Oracle Linux 6
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-07-13 11:44 UTC] graefrath at femu dot rwth-aachen dot de
Description:
------------
While running make test the tests

- dateformat_create_cal_arg.phpt
- dateformat_formatObject_calendar.phpt
- dateformat_formatObject_datetime.phpt
- dateformat_get_set_calendar.phpt
- dateformat_get_set_timezone.phpt
- msgfmt_format_intlcalendar.phpt

execute and fail, even though they should have been skipped. My ICU version is 4.2.1, the tests are supposed to be skipped if the ICU version is < 51.2.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-13 13:53 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2017-07-13 13:53 UTC] requinix@php.net
(If anyone is wondering about the versioning, apparently libicu changed schemes and went from 4.6 to 49. So 4.2.1 ≈ 42.1 and 50.1.2 ≈ 5.0.1.2.)


if (version_compare(INTL_ICU_VERSION, '50.1.2') >=  0) die('skip for ICU < 50.1.2');

Note that the leading "skip" in the die() message is a technical requirement and not necessarily meant to be read as part of the reason (though it often is).
https://qa.php.net/write-test.php#skipif

Either
a) The code is right (skip >= 50.1.2) and the message means the test only applies to < 50.1.2, or
b) The comment is right (skip < 50.1.2) and the code is backwards
I think the former is more likely.

How are the tests failing?
 [2017-07-14 08:13 UTC] graefrath at femu dot rwth-aachen dot de
-Status: Feedback +Status: Open
 [2017-07-14 08:13 UTC] graefrath at femu dot rwth-aachen dot de
Oh I see, I didn't know about the skip thing. I just assumed the code was wrong. My bad! Anyway, here are the actual test diffs:

dateformat_create_cal_arg.diff:

001+ domingo 1 de enero de 2012 00:00:00 GMT+00:00
002+ domingo 8 de Safar de 1433 00:00:00 GMT+00:00
001- domingo%S 1 de enero de 2012 00:00:00 GMT
002- domingo%S 8 de Safar de 1433 00:00:00 GMT
004+ sábado 31 de diciembre de 2011 23:00:00 Hora de las Azores
005+ sábado 7 de Safar de 1433 23:00:00 Hora de las Azores
006+ domingo 8 de Safar de 1433 00:00:00 GMT+00:00
007+ domingo 1 de enero de 2012 00:00:00 GMT+00:00
004- sábado%S 31 de diciembre de 2011 d.C. 23:00:00 Hora %Sde las Azores
005- sábado%S 7 de Safar de 1433 AH 23:00:00 Hora %Sde las Azores
006- domingo%S 8 de Safar de 1433 AH 00:00:00 GMT
007- domingo%S 1 de enero de 2012 00:00:00 GMT

dateformat_formatObject_calendar.diff:

001+ 1 de Jan de 2012 00:00:00
002+ domingo, 1 de Janeiro de 2012 00h00min00s Hora da Europa Ocidental
001- 01/01/2012 00:00:00
002- Domingo, 1 de Janeiro de 2012 0:00:00 Hora %Sda Europa Ocidental
005+ Sun 2012-01-1 00,00,00.000 Portugal (Lisbon)
006+ domingo, 1 de Janeiro de 2012 05h00min00s GMT+03:00
007+ 6 de Safar de 1433 00:00:00
005- Sun 2012-01-1 00,00,00.000 Portugal Time (Lisbon)
006- Domingo, 1 de Janeiro de 2012 5:00:00 GMT+03:00
007- 06/02/1433 00:00:00

dateformat_formatObject_datetime.diff

001+ 1 de Jan de 2012 00:00:00
002+ domingo, 1 de Janeiro de 2012 00h00min00s Hora da Europa Ocidental
001- 01/01/2012 00:00:00
002- Domingo, 1 de Janeiro de 2012 0:00:00 Hora %Sda Europa Ocidental
005+ Sun 2012-01-1 00,00,00.000 Portugal (Lisbon)
006+ domingo, 1 de Janeiro de 2012 05h00min00s GMT+03:00
005- Sun 2012-01-1 00,00,00.000 Portugal Time (Lisbon)
006- Domingo, 1 de Janeiro de 2012 5:00:00 GMT+03:00

dateformat_get_set_calendar.diff:

001+ dimanche 1 janvier 2012 02:00:00 Heure normale de l’Europe de l’Est
001- dimanche 1 janvier 2012 ap. J.-C. 03:00:00 UTC+03:00
006+ dimanche 8 Safar 1433 02:00:00 Heure normale de l’Europe de l’Est
006- dimanche 8 Safar 1433 AH 03:00:00 UTC+03:00
011+ dimanche 1 janvier 2012 00:00:00 UTC+00:00
011- dimanche 1 janvier 2012 ap. J.-C. 00:00:00 UTC

dateformat_get_set_timezone.diff

001+ domingo, 1 de Janeiro de 2012 02h00min00s Hora da Europa Oriental
001- Domingo, 1 de Janeiro de 2012 3:00:00 GMT+03:00
005+ sábado, 31 de Dezembro de 2011 23h00min00s Hora dos Açores
005- Sábado, 31 de Dezembro de 2011 23:00:00 Hor%s %Sdos Açores
009+ domingo, 1 de Janeiro de 2012 01h00min00s Horário Padrão da Europa Central
009- Domingo, 1 de Janeiro de 2012 1:00:00 Hor%s %Sda Europa Central
013+ domingo, 1 de Janeiro de 2012 01h00min00s Horário Padrão da Europa Central
013- Domingo, 1 de Janeiro de 2012 1:00:00 Hor%s %Sda Europa Central
017+ domingo, 1 de Janeiro de 2012 01h00min00s Horário Padrão da Europa Central
017- Domingo, 1 de Janeiro de 2012 1:00:00 Hor%s %Sda Europa Central

msgfmt_format_intlcalendar.diff:

001+ quinta-feira, 17 de Maio de 2012 5:35:36 Depois do meio-dia WEST
001- Quinta-feira, 17 de Maio de 2012 5:35:36 p.m. WEST
 [2017-07-14 09:21 UTC] requinix@php.net
-Summary: Wrong ICU version comparison in some tests +Summary: Some tests fail for ICU 4.2.1 -Status: Open +Status: Wont fix -Package: Testing related +Package: intl
 [2017-07-14 09:21 UTC] requinix@php.net
4.2.1 is 8 years old now (2009). These tests look like they were written in the libicu 49 era, which is 5 years old (2012).

The %S is used by the testing framework as a wildcard and can be ignored.

All the other differences are acceptable, and probably stem from the fact that the different formatting types are documented vaguely. Quoting the docs [1], "the exact result depends on the locale" and "generally" the FULL format, for example, "is completely specified, such as Tuesday, April 12, 1952 AD or 3:30:42pm PST".

I understand that to mean they may change the format over time, and that the only constant aspect is roughly how verbose the output is. So it's quite possible they changed the representations between 4.2.1 and 49.

In fact it's not just possible but likely. It doesn't look like this is the only time formatting differences have been a problem: apparently 4.8 changed outputs again, forcing PHP to loosen the string matching requirements for a few tests, and when 51.2 came in 2013 some tests were completely disabled.

It would be great if you could upgrade your libicu; Oracle Linux 6's yum servers have 4.2.1 while 7's have 50.1.2 (late 2012) available, and of course you can always build from any source version you want (currently at 59.1).
http://site.icu-project.org/download

Or you can accept that some of the tests won't pass - having seen the diffs you know that it's not so much a technical problem as it is about formatting changes. However if you're planning to use the built-in formats for presentation to users then you'll be stuck with the outdated styles used by 4.2.1; using manual format strings is still an option, of course.

Someone with more knowledge about libicu and ext/intl may know better, but I don't think this is an issue that PHP should try to resolve.

[1] http://userguide.icu-project.org/formatparse/datetime#TOC-Producing-Normal-Date-Formats-for-a-Locale
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Nov 28 19:01:24 2020 UTC