"timezone (Etc/GMT+6) is not a known timezone" errors with php v8.1.14

[rfeese]

Preconditions (*)

1. OpenMage 19.4.20, 19.4.21 (both tested)
2. php v8.1.14 (php v8.1.13 does not exhibit the issue)
3. There appears to be a problem with parsing timezones with "plus codes" (ex: "Etc/GMT+6") in php v8.1.14. I think this may be a new bug although the use of these zones is apparently discouraged in php (see php doc link below).
4. php bug report that may be relevant: DateTimeZone fails to parse time zones that contain the "+" character php/php-src#10218
5. php docs that discourage use of these zones: https://www.php.net/manual/en/timezones.others.php
6. I believe that there are zones in the old Zend libs that include these old timezone definitions, and perhaps they can just be eliminated. At this point I am not sure if this is a php bug or what.
7. Example of problematic zones in Zend data:

   magento-lts/lib/Zend/Locale/Data/windowsZones.xml

   Line 17 in 984dfcb

   <mapZone other="Dateline Standard Time" territory="001" type="Etc/GMT+12"/>

Steps to reproduce (*)

1. Edit a product in admin interface and click save.
2. You will receive an error like: "timezone (Etc/GMT+6) is not a known timezone"
3. In exception log, there should be an error like: Mage_Eav_Model_Entity_Attribute_Exception: timezone (Etc/GMT+6) is not a known timezone in /var/www/html/marketplace.unl.edu/app/code/core/Mage/Core/Model/Config.php:1450
4. Note that other things break as well -- customer check-out for instance.

Expected result (*)

1. Expect to not have timezone errors.

Actual result (*)

1. error like: "timezone (Etc/GMT+6) is not a known timezone"
2. In exception log, there should be an error like: Mage_Eav_Model_Entity_Attribute_Exception: timezone (Etc/GMT+6) is not a known timezone in /var/www/html/marketplace.unl.edu/app/code/core/Mage/Core/Model/Config.php:1450

[addison74]

As you may know, OpenMage has taken an important step and recently adopted ZF1-Future, which completely replaces everything that previously existed in /app/code/core/Zend and /lib/Zend directories. Until we find a solution, I think it would be advisable to post the issue in this repository https://github.com/Shardj/zf1-future/issues too.

It remains to be analyzed if we follow the PHP recommendations then changes are necessary, most likely all GMT-n/GMT+n variants will be removed, but the change should be made in ZF1-Future repository, if it is not possible we will find a patch type solution.

[elidrissidev]

Issue confirmed directly after upgrading to PHP 8.1.14.

[fballiano]

it kinda seems a php bug but maybe we could open an issue to https://github.com/Shardj/zf1-future to remove those timezones?

[rfeese]

I am not sure what code is actually causing this error. Has anyone been able to narrow it down any further?

[sreichel]

@rfeese @elidrissidev Can you please check your config? (Admin -> Config -> General -> Locale -> Timezone)

I think invalid timezones can be removed here: Mage_Core_Model_Locale::getOptionTimezones()

(.... or search/debug date_default_timezone_get() calls ... ?!?)

edit: tested with php8.2 and have no errors ....

[sreichel]

it kinda seems a php bug but maybe we could open an issue to https://github.com/Shardj/zf1-future to remove those timezones?

ZF1 uses this file .... https://github.com/unicode-org/cldr/blob/main/common/supplemental/windowsZones.xml

[Sdfendor]

Do I need to set up such a timezone in the store config to be affected by this problem?

Edit: to be affected one needs e.g. switch the system timezone to one mentioned above. After that bug is reproducible (8.1.14). Wasn't sure about that after reading the issue description above (OpenMage 20.0.16).

[elidrissidev]

@sreichel AFAIK this happens only in 8.1.14, not 8.2. and my timezone is the default from sample data pack.

[Sdfendor]

@elidrissidev I can reproduce the bug in PHP 8.1.14 as well as 8.2.1 (in OpenMage 20.0.16, I'm aware that this is not the most recent OM version).

[addison74]

From what I have analyzed, we are not the only ones affected and the reports are starting to appear. We don't have to modify OpenMage or ZF1-Future. It is a bug in PHP related to the recently timelib update. @derickr should revert the PR until a better solution is found. Details here php/php-src#9700.

Until then, those who face this issue must establish temporary a timezone in the Continent/City format.

[fballiano]

Do I have to enable DeveloperMode or something to see this problem?

[elidrissidev]

Do I have to enable DeveloperMode or something to see this problem?

Only requirement is to have PHP 8.1.14/8.2.1 and you should the error when you try to save any product (don't forget to reload php-fpm if you've just updated).

[elidrissidev]

So here's where the "Etc/GMT+n" timezone is coming from: Zend_Date's constructor is trying to infer the timezone from the given date if it's a string (e.g. 2022-12-27T08:15:24-08:00), and of course since it can't establish a mapping between the offset and the proper Continent/City timezone name, it calls Zend_Date::getTimezoneFromString() which uses the generic "Etc/GMT".

https://github.com/Shardj/zf1-future/blob/dadd0c2081377cf4333127861916cc88b87009bb/library/Zend/Date.php#L188-L191

It's not clear to me yet how to fix this temporarily while waiting for a fix from upstream.

[derickr]

You should really not use the Etc/GMT+1 variants. First of all, these are no different from normal GMT±x names, but most of all because the + and - in them are actually the wrong way around. Etc/GMT+5 is actually GMT-5.

Having said that, this is now fixed for PHP 8.1.15 and PHP 8.2.2 as per php/php-src@d12ba11

[fballiano]

Thank you so much @derickr!

[addison74]

Totally agree. Etc+n/Etc-n should be avoided from now on because they can produce different results. This is actually the official recommendation that was posted before https://www.php.net/manual/en/timezones.others.php.

[elidrissidev]

@addison74 Issue opened on zf1-future to address this.

[addison74]

If the PHP team warns us not to use those timezone formats, why should they be maintained in ZF1-Future? You did very well @elidrissidev.

[sreichel]

Should PHP 8.1.14 and 8.2.1 be added to composers conflict section?

[fballiano]

Should PHP 8.1.14 and 8.2.1 be added to composers conflict section?

this seems like a great idea

[sreichel]

Mhhh. conflict sections seems wrong, but whats the correct pattern to exclude specific versions for ... ?

    "require": {
        "php": ">=7.3 <8.2",

[fballiano]

I was checking it, it could be something like php": ">=7.3 <=8.1.13 >8.1.14", could it work? maybe we could remove the 8.2 constraint yet?