(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?

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

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