IntlDateFormatter::localtime() unexpectedly causes time zone to be changed if specified

[Fischer-Bjoern]

Description

The following code:

<?php

$oIntlDateFormatter = new IntlDateFormatter("en_GB");
$oIntlDateFormatter->setTimeZone('Europe/Berlin');
$oIntlDateFormatter->setPattern('VV');

$oIntlDateFormatter->parse('America/Los_Angeles', $offsetResult);
var_dump($oIntlDateFormatter->getTimeZone()->getID());

$oIntlDateFormatter->localtime('America/Los_Angeles');
var_dump($oIntlDateFormatter->getTimeZone()->getID());

Resulted in this output:

string(13) "Europe/Berlin"
string(19) "America/Los_Angeles"

But I expected this output instead:
Either:

string(13) "Europe/Berlin"
string(13) "Europe/Berlin"

Or

string(19) "America/Los_Angeles"
string(19) "America/Los_Angeles"

IntlDateFormatter should either consistently keep the originally set time zone or consistently overwrite the time zone whenever different time zone data is supplied.

IntlDateFormatter::localtime() causes the time zone within an IntlDateFormatter object to be changed, if a time zone was provided in the used date/time pattern. This is nowhere mentioned in the documentation of IntlDateFormatter::localtime() and in contrast IntlDateFormatter::parse() does not behave this way. This is why I think the behaviour of IntlDateFormatter::localtime() is not intentional.

In contrast when I look at DateTime::createFromFormat(), a time zone supplied in the $datetime parameter consistently overrides a supplied $timezone parameter.

Having looked a bit into PHPs code, It seems like DateTime::createFromFormat() and internally always generates a field-based time value and generates a date/time representation from that, just like IntlDateFormatter::localtime(). So this may be also triggering the change of the time zone.
IntlDateFormatter::parse() on the other hand appears to to only call into the ICU library to get a parse the supplied date/time string.

PHP Version

PHP 8.3.4

Operating System

Ubuntu 22.04.1

[devnexen]

Your analysis sounds correct, however I need to dig in to figure out if the behavior difference is intentional.

[devnexen]

As far I m concerned, it had been this way from the very existence of the extension and on purpose, thus this is not bug, changing it would be a BC. Eventually can be introduced an optional argument ; at best.

[hormus]

https://unicode-org.github.io/icu/userguide/format_parse/datetime/#datetime-format-syntax
Symbol: V
Meaning: long timezone ID
Pattern: VV
Example Output: Europe/Berlin

<?php

$oIntlDateFormatter = new IntlDateFormatter(
    'en_US',
    IntlDateFormatter::FULL,
    IntlDateFormatter::FULL,
    'UTC',
    IntlDateFormatter::GREGORIAN
);
$oIntlDateFormatter->setLenient(FALSE);

$oIntlDateFormatter->setPattern('VV');

$offsetResult = null;
$a = $oIntlDateFormatter->parse('Europe/Berlin', $offsetResult);
$b = $oIntlDateFormatter->getTimeZone()->getID();

$c = $oIntlDateFormatter->localtime('Europe/Berlin');
$d = $oIntlDateFormatter->getTimeZone()->getID();
$e = intl_get_error_message();

if($a) {
var_dump($a);
var_dump($b);
}
if(is_array($c)) {
var_dump($c);
var_dump($d);
}
var_dump($e);

?>

Expected result:

int(-3600)
string(3) "UTC"
array(9) {
  ["tm_sec"]=>
  int(10)
  ["tm_min"]=>
  int(24)
  ["tm_hour"]=>
  int(19)
  ["tm_year"]=>
  int(124)
  ["tm_mday"]=>
  int(24)
  ["tm_wday"]=>
  int(0)
  ["tm_yday"]=>
  int(84)
  ["tm_mon"]=>
  int(2)
  ["tm_isdst"]=>
  int(0)
}
string(13) "Europe/Berlin"
string(12) "U_ZERO_ERROR"

IntlDateFormatter::Parse return timestamp (-3600 seconds is 1 hour)
For localtime Europe/Berlin is 19:24:10,
For localtime UTC is 18:24:10

The localtime function for local output sets the time zone, otherwise the output may have a different date and time.
Europe/Berlin is UTC+01:00
UTC is UTC

[Fischer-Bjoern]

Interesting point. I guess it would be helpful if localtime() documented this then?!