date_i18n() produces invalid output for numerical time zones

[Rarst]

date_i18n() only attempts to use get_option( 'timezone_string' ) for timezone information. This option is empty when numerical offset is saved as time zone in settings.

Code to reproduce:

// Kiev
var_dump( get_option( 'timezone_string' ), get_option( 'gmt_offset' ) ); // 'Europe/Kiev', 2
var_dump( date_i18n( DATE_W3C, get_the_date( 'U' ) ) ); // 2015-12-03T12:22:22+02:00 correct

// UTC+2
var_dump( get_option( 'timezone_string' ), get_option( 'gmt_offset' ) ); // '', '2'
var_dump( date_i18n( DATE_W3C, get_the_date( 'U' ) ) ); // 2015-12-03T12:22:22+00:00 wrong

[SergeyBiryukov]

Related: #25768

[swissspidy]

Introduced in [16203], see #8153

[pbearne]

The code tests if the options is returned and skips the code that uses it if not set

[pbearne]

start of unit test

[pbearne]

in the code, we test for if the option is empty/false and ship the use if it is

<?php
$timezone_string = get_option( 'timezone_string' );
if ( $timezone_string ) {....

So it doesn't error but it doesn't return a date with the offset

the problem is that you can have a more than one time zone for more than one offset and the summer/winter time changes are per timezone no offset.

There is a mapping from time zone to offset but not from offset to time zone as don't know which time zone to set

Maybe the need to discourage the setting of the offset in the options and that way always have a timezone.

The default enter for get_option( 'timezone_string' ) is emtpy not even GMT

[Rarst]

While the reliable conversion from offset to timezone string isn't possible it should still use offset in date output. Otherwise it's just clearly broken value, off from real value by that many hours.

Obviously only using real timezones would be preferable, but I am not sure if it's desirable/possible to drop offsets from UI (backwards compat and everything).

[Rarst]

Implements correct output for numeric offsets, without going through time zone object.

[Rarst]

Skipped I format for DST which is irrelevant for the case.

[Rarst]

Patch with unit test.

[flixos90]

In 43387:

Date/Time: Add support for gmt_offset to date_i18n().

Prior to this change, date_i18n() only supported the timezone_string option, causing incorrect timezones to appear in formatted dates on sites that still rely on the gmt_offset option.

Props Rarst.
Fixes #34835.