Inconsisten IntlDateFormatter between bullseye and bookworm builds

[rmikalkenas]

Description

Inconsistent output can be seen with IntlDateFormatter between php:8.3.2-cli-bullseye and php:8.3.2-cli-bookworm docker builds.

For whatever reason bookworm build adds a narrow non breakable space (nnbps) to formatted date.

The following code:

<?php
// composer require "symfony/var-dumper"
require_once __DIR__ . '/vendor/autoload.php';

$formatter = new IntlDateFormatter(
    Locale::getDefault(),
    IntlDateFormatter::MEDIUM,
    IntlDateFormatter::SHORT,
    'UTC'
);
dump($formatter->format(new DateTimeImmutable('2024-01-29 15:24:37', new DateTimeZone('UTC'))));

Resulted in this output:

// Output with: php:8.3.2-cli-bullseye
// "Jan 29, 2024, 3:24 PM"

// Output with: php:8.3.2-cli-bookworm
// "Jan 29, 2024, 3:24\u{202F}PM"

PHP Version

8.3.2

Operating System

Debian

[devnexen]

The icu4c library version surely differ between those two.

[hormus]

@devnexen ?
It's for icu4c or icu4j
#11600 thin space U+2009 or U+202F narrow no-break space for ICU update 72.1 https://icu.unicode.org/download/72

[rmikalkenas]

@TimWolla could you provide more details on why task has been closed and status changed to invalid?

Is it expected that with the new build and thus new icu version we should adjust our php applications to work with slightly different date formatter output?

[TimWolla]

Yes. You generally should not expect the ICU output format to be stable, because as with any other software there are bugfixes and the output is meant for human consumption, not for machines. If languages evolve or if a language is incorrectly implemented the output will change. In fact I'd argue that this specific change is a bugfix, because breaking the line before the "PM" would easily become confusing.

[rmikalkenas]

@TimWolla make sense, thanks for explanation 🙏