DateTimeZone Doesn't Handle Etc/GMT+10 in Php8.1.14 and Php8.2.1

[oleibman]

Description

The following code:

<?php
new DateTimeZone('Etc/GMT+10');

Resulted in this output:

Fatal error: Uncaught Exception: DateTimeZone::__construct(): Unknown or bad timezone (Etc/GMT+10) in C:\Users\OwenLeibman\Downloads\php-8.1.14-Win32-vs16-x64\tzbug.php:2
Stack trace:
#0 C:\Users\OwenLeibman\Downloads\php-8.1.14-Win32-vs16-x64\tzbug.php(2): DateTimeZone->__construct('Etc/GMT+10')
#1 {main}
  thrown in C:\Users\OwenLeibman\Downloads\php-8.1.14-Win32-vs16-x64\tzbug.php on line 2

But I expected no output instead:

This error is introduced in Php8.1.14 and 8.2.1 (and 8.3 nightlies). It was not present in 8.1.13 or 8.2.0. It appears that all timezones of the form Etc/GMT+whatever fail; Etc/GMT-whatever continues to work. Etc/GMT+whatever continues to be listed as a supported timezone at https://www.php.net/manual/en/timezones.others.php

PHP Version

Php 8.2.1 and Php 8.1.14

Operating System

Windows

[damianwadley]

Duplicate of #10218.

Etc/GMT+whatever continues to be listed as a supported timezone at https://www.php.net/manual/en/timezones.others.php

The very first sentence on that page says not to use them.

[Zenexer]

@damianwadley, the trouble is that these are returned by listIdentifiers when passed ALL_WITH_BC. Even if these are deprecated, the following code shouldn't fail: https://3v4l.org/HMcFD

[derickr]

@Zenexer This is fixed already, through #10218. I think @damianwadley was too quick labelling this as "not planned". It's not for him to decide that.

[damianwadley]

"Not planned" in that this specific issue isn't going to have any associated work - because it's a duplicate of another one. The issue of ALL_WITH_BC is something separate.

HMcFD should begin working again when 8.2.2/8.1.15 releases next week.

[Zenexer]

Yup, I just want it on the record--for other people landing here from Google--that this is not, in fact, expected behavior. The code snippet at the 3v4l link should work. You shouldn't be deliberately using these timezones, but anything in listIdentifiers shouldn't throw an exception when passed to DateTimeZone's constructor in the same process. It is a regression, and a fix was merged, although you shouldn't take it as a sign that those timezones are safe to use outside of this specific context.