Site Crashed U_ILLEGAL_ARGUMENT_ERROR in IntlDateFormatter

EDIT: Affects 8.1.25, 8.2.12, and 8.3.0RC3+

Hello All,
1.5.8 (forget the revision) on php 8.2. Woke this morning to white screens in admin and front end.

Code:

---

[02-Nov-2023 10:05:18 America/New_York] Request URI: /manufactuername-m-1.html, IP address: 11.22.33.44
--> PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /home/account/www.website.com/includes/classes/zcDate.php:87
Stack trace:
#0 /home/account/www.website.com/includes/classes/zcDate.php(87): IntlDateFormatter->__construct('C', 3, -1)
#1 /home/account/www.website.com/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /home/account/www.website.com/includes/autoload_func.php(47): zcDate->__construct()
#3 /home/account/www.website.com/includes/application_top.php(237): require('/home/account...')
#4 /home/account/www.website.com/index.php(25): require('/home/account...')
#5 {main}
  thrown in /home/account/www.website.com/includes/classes/zcDate.php on line 87.

---

Please help.

Thank you,
John

Me too, thought it was the hosting service

I just switched php back to 8.0 and it's running again seemingly without errors or warnings. I'd really like to get this resolved though so we can go back to 8.2.

Thanks again,
John

This has just started happening on my test site. Live is ok.
It appears that this code in includes/classes/zcDate.php is the issue

Code:

---

            $this->locale = setlocale(LC_TIME, 0);

            // -----
            // Using the current locale, retrieve the locale-specific 'short' date and time
            // formats.
            //
            $format = new IntlDateFormatter(
                $this->locale,
                IntlDateFormatter::SHORT,
                IntlDateFormatter::NONE
            );

---

The issue appears to be that if setlocale has not been called before zcDate is initialised the server returns a local of "C" this appears to mean not set yet.
I found this from @DrByte https://github.com/php/php-src/issues/12561#issuecomment-1786428271

I don't know enough to fix this.

I suspect that zcDate class is being initialised before setlocale is set in

includes/languages/lang.english.php
YOURADMIN/languages/lang.english.php

If I add the setlocale from the language file to the begining index.php and YOURADMIN/index.php the system seems to work OK. This is a workaround and not a solution! I will try a few other things to find a solution. Mean while if @drByte, @lat9... could look at this.

I agree. index.php requires includes/application_top.php, which loads the autoloaders including config.core.php, which calls zcDate.php
only after application_top.php does all its stuff are the language files parsed, including the setlocale
set locale may need to be moved to configure.php instead...

lol, now that I'm all caught up on github convo I see that drbyte has just about decided the same.
https://github.com/zencart/zencart/issues/6037

Yes, the latest updates to PHP (PHP 8.1.25 and 8.2.12) added a sudden fatal error when the locale is not explicitly configured on the server.
They claim to be backing it down in subsequent PHP 8.1 (8.1.26) and 8.2 (8.2.13) releases, but appear to be keeping it in 8.3-onward, so a workaround is needed:
ie: configure a default locale in PHP.

IMO the simplest fix for existing stores, is simply to add a default locale to your configure.php files:

/includes/configure.php
and
/admin/includes/configure.php

Code:

---

@setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']);

---

(Obviously, you could put your own preferred language locale in there, but is overridden later anyway. See note below.)

It can be put on its own line anywhere after the opening "<php" line or at the bottom of the file.

Zen Cart's default application_top bootstrapping process will auto-detect whatever language the store and/or customer really wants, and will reset it to that before any normal output is generated. So don't need to do any additional changes to your language files etc.

This doesn't seem to work on my test installation. PHP 8.1. Fails on both storefront and admin.

I appreciate the input from the Zen Cart team.

But the proposed fix is also not working on my test cart. ZC 1.5.8, PHP 8.2

Hmmm. Investigating ...

proposed

HTML Code:

---

@setlocale(LC_TIME, 'en');

---

doesn't work, but the complete:

Code:

---

$locales = ['en_US', 'en_US.utf8', 'en', 'English_United States.1252'];
@setlocale(LC_TIME, $locales);

---

DOES work. No clue why.

My bad. Turns out 'en' alone isn't "valid" either. And that's what I had in my clipboard when I pasted. Doh!

EDITED: now recommending:

Code:

---

@setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']);

---

Add this to the end of includes/configure.php and YOUR_ADMIN/includes/configure.php

Quote:

---

Originally Posted by DrByte

My bad. Turns out 'en' isn't "valid" either. And that's what I had in my clipboard when I pasted. Doh!

Use:

Code:

---

@setlocale(LC_TIME, 'en_US');

---

---

I can confirm this works in my testing. en is so close to en_US. :D

Confirmed on admin and storefront in PHP 8.1. Thanks, @drbyte!

I updated my "fix" with adding UTF-8 fallback, just in case.
(FYI The hyphenated uppercase en_US.UTF-8 works on my dev site, where the en_US.utf8 lowercase without hyphen shows as invalid when used on its own. Might be different on different servers with different locale packs installed at the server level.)

And for local PC servers running Windows, it seems 'en-US' may be what's needed.

Confirmed working on php 8.2. Thank you all very much!

Best,
John

So I was getting the HTTP 500 error when going to my store as a user or an admin. I switched the PHP to 8 and still same issue, I switched back to 8.1 and it works.

I was getting the following error

Quote:

---

[08-Nov-2023 20:52:03 America/New_York] PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /homepages/website/store/includes/classes/zcDate.php:90
Stack trace:
#0 /homepages/website/store/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /homepages/website/store/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /homepages/website/store/includes/autoload_func.php(47): zcDate->__construct()
#3 /homepages/website/store/Skill-ieE-trusT/includes/application_top.php(42): require('/homepages/36/d...')
#4 /homepages/website/store/Skill-ieE-trusT/home.php(9): require('/homepages/36/d...')
#5 /homepages/website/store/Skill-ieE-trusT/index.php(11): require('/homepages/36/d...')
#6 {main}
thrown in /homepages/website/store/includes/classes/zcDate.php on line 90

[08-Nov-2023 20:52:03 America/New_York] Request URI: /store/Skill-ieE-trusT/, IP address: 136.226.82.111
--> PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /homepages/website/store/includes/classes/zcDate.php:90
Stack trace:
#0 /homepages/website/store/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /homepages/website/store/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /homepages/website/store/includes/autoload_func.php(47): zcDate->__construct()
#3 /homepages/website/store/Skill-ieE-trusT/includes/application_top.php(42): require('/homepages/36/d...')
#4 /homepages/website/store/Skill-ieE-trusT/home.php(9): require('/homepages/36/d...')
#5 /homepages/website/store/Skill-ieE-trusT/index.php(11): require('/homepages/36/d...')
#6 {main}
thrown in /homepages/website/store/includes/classes/zcDate.php on line 90.

---

spoke too soon. I did add the code to the config files and it fixed it.

Code:

---

@setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']);

---

Few month ago I submitted on github a re-write of class file zc_date.php based on intl date_format object instead of srftime(). It was not accepted at the time but it might change now. Basically instead of using depracated strftime parameters it uses datefm_create if installed and if not date(). I made it compatible with strftime parameters so old plugins still work.
I use this mod on my live site and some test sites and was not affected when updating to PHP 8.1.25 or 8.2.12!
If you want to try it you can just copy class file zc_date.php (after backing up your original version). If you want to be more efficient and eliminate old strftime parameters copy/merge all other files.
By the way I hope that in new Zencart 2.0 strftime % parameter won't be use any more.
here is the link to github repo: https://github.com/piloujp/zcDate_mod

Noting that the zcDate.php class is PHP version-specific, using strftime for PHP versions < 8.1 and using the IntlDateFormatter class (if that PHP extension is installed) otherwise.

Quote:

---

Originally Posted by lat9

Noting that the zcDate.php class is PHP version-specific, using strftime for PHP versions < 8.1 and using the IntlDateFormatter class (if that PHP extension is installed) otherwise.

---

I did not do detailed explanation as it was already explained few month ago but I made it backward compatible. It uses IntlDateFormatter (PHP >=5.3.0 with PECL >=1.0.0) if avialable as it is possible (although very rare) to remove this extension in PHP settings, then date_format (PHP >= 5.2.0) if not. Strftime % parameters are accepted as input parameters.
Compatibility should go back to ZenCart 1.3.9 although I did not test it and won't... This was made for Zencart 1.5.8 (PHP >= 7.3) and above anyway.

post 7 by dr byte fixed this issue for me.

for those reading/searching on solution why php 8.1 and 8.2 white screens the site and php 8.0 works fine.
fresh install tested. 1.5.8a

Quote:

---

Originally Posted by DrByte

My bad. Turns out 'en' alone isn't "valid" either. And that's what I had in my clipboard when I pasted. Doh!

EDITED: now recommending:

Code:

---

@setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']);

---

Add this to the end of includes/configure.php and YOUR_ADMIN/includes/configure.php

---

That fix for a blank store with the log "Uncaught Error: Found unconstructed IntlDateFormatter" worked for me! I changed the two cofigure.php files and now both the customer-facing page and the admin page load on my test install.

Quote:

---

Originally Posted by DrByte

My bad. Turns out 'en' alone isn't "valid" either. And that's what I had in my clipboard when I pasted. Doh!

EDITED: now recommending:

Code:

---

@setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']);

---

Add this to the end of includes/configure.php and YOUR_ADMIN/includes/configure.php

---

That fixed worked for me when the customer-facing page and the admin page were both blank and the log listed an "Uncaught Error: Found unconstructed IntlDateFormatter". Thanks.

Hi Guys,
I tested 1.5.8a fresh install with PHP 8.11 and tested all patches without sucess. When using PHP 7.4 all it works without problem. I assume if PHP 8.0 is used it will also work, as per other forum posts(also tested php 8.010 and it works). 2.0 is supposed to solve this issue. The important question for us is the compatibility of the plug ins in version 1.5.8a and 2.0. If the plugins are compatible with both these versions then we go straight to version 2.0. If not we have to sort out the issues with 1.5.8 till the 2.0 with our pluggins are compatible. Any hints of what we maybe doing wrong with the PHP 8.1+ patch is welcome.

Quote:

---

Originally Posted by Georgecy

Hi Guys,
I tested 1.5.8a fresh install with PHP 8.11 and tested all patches without sucess. When using PHP 7.4 all it works without problem. I assume if PHP 8.0 is used it will also work, as per other forum posts(also tested php 8.010 and it works). 2.0 is supposed to solve this issue. The important question for us is the compatibility of the plug ins in version 1.5.8a and 2.0. If the plugins are compatible with both these versions then we go straight to version 2.0. If not we have to sort out the issues with 1.5.8 till the 2.0 with our pluggins are compatible. Any hints of what we maybe doing wrong with the PHP 8.1+ patch is welcome.

---

I'm not clear on what the issue you're facing is; see post #24 in this thread ... has that change provided by DrByte been applied?

Hi Cindy,
The patch @setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']); has been applied to both configure files without success. I initially use GB instead of US but at the end I used the exact statement above. I tried also to changed the Time Zone to Europe/Athens but without success.
[09-May-2024 17:05:51 Europe/Athens] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'Europe/Athens': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90

When going back to PHP 7.4 or 8.0 the blank pages go away and the the store works as expected.

The logs are the shown below

[09-May-2024 13:32:46 UTC] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'UTC': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90
Stack trace:
#0 /includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /includes/autoload_func.php(47): zcDate->__construct()
#3 /admin!/includes/application_top.php(42): require('...')
#4 /admin!/login.php(8): require('...')
#5 /admin!/index.php(11): require('...')
#6 {main}
thrown in /includes/classes/zcDate.php on line 90

[09-May-2024 13:32:46 UTC] Request URI: /admin!/index.php?cmd=login&camefrom=index.php, IP address: xxxxxxx
--> PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'UTC': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90
Stack trace:
#0 /includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /includes/autoload_func.php(47): zcDate->__construct()
#3 /admin!/includes/application_top.php(42): require('...')
#4 /admin!/login.php(8): require('...')
#5 /admin!/index.php(11): require('...')
#6 {main}
thrown in /includes/classes/zcDate.php on line 90.

Still trying to figure out what's going on. This link: https://github.com/zencart/zencart/b...te.php#L87-L91

... identifies lines 87 through 91 of the zcDate.php class for zc158a. The fact that your logs show an issue being thrown on line 90 is what's (er) throwing me off.

Setting on line 90 'none' means it uses PHP's or system's default. There might be some bad setting in php.ini or somewhere on the server, just an idea.

Quote:

---

Originally Posted by pilou2

Setting on line 90 'none' means it uses PHP's or system's default. There might be some bad setting in php.ini or somewhere on the server, just an idea.

---

The error getting thrown could be the result of date.timezone not being set correctly in php.ini.

Thanks guys. I added in PHP.ini the following date.timezone = Europe/Athens and also I cleaned installed Zencart 2.0 tested with PHP 8.11 and PHP 8.3. The problem is the same. When I go to PHP 8.0 the installation works. The logs of ZC 2.0 are listed below. No patch was added in ZenCart 2.0.

[10-May-2024 11:04:23 Europe/Athens] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'Europe/Athens': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:89
Stack trace:
#0 /includes/classes/zcDate.php(89): IntlDateFormatter->__construct()
#1 /includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /includes/autoload_func.php(47): zcDate->__construct()
#3 /includes/application_top.php(253): require('...')
#4 /index.php(25): require('...')
#5 {main}
thrown in /includes/classes/zcDate.php on line 89

Well, you really need to help us more by giving infos about your settings, like what system you are on, what is your actual locale setting in php.ini, lang.english.php or whatever language file you use?
Did you add some code to set timezone in Zen Cart?...
With information I have now, here is what I can see:

Your problem is not related to this thread original post that was a bug in a specific PHP version you do not used.
The problem disappears when using PHP 8.0 or lower because in these cases Zen Cart do not use IntlDateFormatter.
IntlDateFormatter crashes PHP because it is given bad information/settings.
Probably not the solution but in php.ini, you should have

PHP Code:

---

date.timezone = "Europe/Athens" 


---

rather than

PHP Code:

---

date.timezone = Europe/Athens 


---

.

When timezone or other necessary setting is not define in the code, IntlDateFormatter uses PHP's one (good or bad) and if PHP's locale/timezone is not set, PHP will try to use system setting with more or less success depending on system.

Thanks a lot for the reply.
I am using Abyss webserver on MacOs 10.12. I can use PHP 7.4, 8.1, 8.2 and 8.3.
In Php.ini I use date.timezone = "Europe/Athens". I tested also Europe/Nicosia and Asia/Nicosia

I do clean installation from the original code zencart-1.5.8a-patched-2024-04-05. I copied the actual folder in htdocs and run the ZC_Install. The database is clean and populated by the demo products. When Installation is finished the ZC-install requests removal of ZC_Install and gives links to both front end and the admin of the store. Both links show a blank page with the log as shown below. If I go to PHP 8 then all works.

I added all the variations of the @setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']); in both Admin/configure and configure without success. I used also @setlocale(LC_TIME, ['el_GR', 'el_GR.utf8', 'el_GR']); I have set on the computer also Greece as region. I am actually in Cyprus.
In the lang.english.php I used also the original US setting and variations as this one $locales = ['el_GR', 'el_GR.utf8', 'en', 'el.Greece'];

It takes me less than 5 minutes to make a new installation either 1.5.8 or 2.0 just give me some recommendations and I will test them and let you know of the results.

Thanks a lot


[11-May-2024 12:32:50 Europe/Athens] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'Europe/Athens': U_ILLEGAL_ARGUMENT_ERROR in /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php:90
Stack trace:
#0 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/autoload_func.php(47): zcDate->__construct()
#3 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/application_top.php(237): require('...')
#4 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/index.php(25): require('...')
#5 {main}
thrown in /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php on line 90

Quote:

---

Originally Posted by pilou2

Well, you really need to help us more by giving infos about your settings, like what system you are on, what is your actual locale setting in php.ini, lang.english.php or whatever language file you use?
Did you add some code to set timezone in Zen Cart?...
With information I have now, here is what I can see:

Your problem is not related to this thread original post that was a bug in a specific PHP version you do not used.
The problem disappears when using PHP 8.0 or lower because in these cases Zen Cart do not use IntlDateFormatter.
IntlDateFormatter crashes PHP because it is given bad information/settings.
Probably not the solution but in php.ini, you should have

PHP Code:

---

date.timezone = "Europe/Athens" 


---

rather than

PHP Code:

---

date.timezone = Europe/Athens 


---

.

When timezone or other necessary setting is not define in the code, IntlDateFormatter uses PHP's one (good or bad) and if PHP's locale/timezone is not set, PHP will try to use system setting with more or less success depending on system.

---

testssdddd

Thanks a lot for the reply.
I am using Abyss webserver on MacOS 10.12 with a selection of PHP from 7.4-8.1-8.2-8.3.
In PHP.ini I tested date.timezone = "Europe/Athens" and date.timezone = "Europe/Nicosia"

I do clean installation from the zencart-1.5.8a-patched-2024-04-05 using ZC_Install. After installation is complete the links to both Front end and admin show a blank page. i added in both configures the @setlocale(LC_TIME, ['el_GR', 'el_GR.utf8', 'el_GR']); also as Dr Byte gave it also localised.
In lang.English.php I used the default and also the localised $locales = ['el_GR', 'el_GR.utf8', 'en', 'el.Greece'];

In all cases I get a log error as shown below. If I use php 8 then everything works.

I can set up a new installation in a few minutes. I you have any recomendation I can test it and let you know the results.

Thanks a lot.

[11-May-2024 12:32:50 Europe/Athens] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'Europe/Athens': U_ILLEGAL_ARGUMENT_ERROR in /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php:90
Stack trace:
#0 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/autoload_func.php(47): zcDate->__construct()
#3 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/application_top.php(237): require('...')
#4 /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/index.php(25): require('...')
#5 {main}
thrown in /Applications/Abyss Web Server/htdocs/zencart-1.5.8a/includes/classes/zcDate.php on line 90

Try creating a small .php file in the site's root to determine which timezone-identifiers are available to you. See this (https://www.php.net/manual/en/dateti...dentifiers.php) php.net documentation of the way to do this.

Instead of looping through only the first 5 identifiers as in that example, use foreach to list them all. It could easily be that your webhost's PHP installations don't include either Europe/Athens or Europe/Nicosia.

I just want to add you should check that PHP 'intl' extension is installed, just to be sure. Without it, IntlDateFormatter won't work.
Test lat9 proposed should give us important information.

Hi Guys,
timezone-identifiers available from @lat instructions are listed at the end. The important for my case is Asia/Nicosia, Europe/Athens, which are available.( Running Joomla 4 system report, on same PHP, it shows also Europe/Nicosia and UTC as default timezone. Joomla has no problem with the PHP 8.1.1).

The actual timezone declared in php.ini is date.timezone = "Europe/Athens"

The Intl extension is also available.
I entered also in php.ini
[intl]
intl.default_locale = el_GR.UTF-8 which it had no effect on the issue.

Attached also screenshot From info.php
Attachment 20608

Asia/Aden, Asia/Almaty, Asia/Amman, Asia/Anadyr, Asia/Aqtau, Asia/Aqtobe, Asia/Ashgabat, Asia/Atyrau, Asia/Baghdad, Asia/Bahrain, Asia/Baku, Asia/Bangkok, Asia/Barnaul, Asia/Beirut, Asia/Bishkek, Asia/Brunei, Asia/Chita, Asia/Choibalsan, Asia/Colombo, Asia/Damascus, Asia/Dhaka, Asia/Dili, Asia/Dushanbe, Asia/Famagusta, Asia/Gaza, Asia/Hebron, Asia/Ho_Chi_Minh, Asia/Hong_Kong, Asia/Hovd, Asia/Irkutsk, Asia/Jakarta, Asia/Jayapura, Asia/Jerusalem, Asia/Kabul, Asia/Kamchatka, Asia/Karachi, Asia/Kathmandu, Asia/Khandyga, Asia/Kolkata, Asia/Krasnoyarsk, Asia/Kuala_Lumpur, Asia/Kuching, Asia/Kuwait, Asia/Macau, Asia/Magadan, Asia/Makassar, Asia/Manila, Asia/Muscat, Asia/Nicosia, Asia/Novokuznetsk, etc...., Europe/Amsterdam, Europe/Andorra, Europe/Astrakhan, Europe/Athens, Europe/Belgrade, etc....

Quote:

---

Originally Posted by Georgecy

Hi Cindy,
The patch @setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']); has been applied to both configure files without success. I initially use GB instead of US but at the end I used the exact statement above. I tried also to changed the Time Zone to Europe/Athens but without success.
[09-May-2024 17:05:51 Europe/Athens] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'Europe/Athens': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90

When going back to PHP 7.4 or 8.0 the blank pages go away and the the store works as expected.

The logs are the shown below

[09-May-2024 13:32:46 UTC] PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'UTC': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90
Stack trace:
#0 /includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /includes/autoload_func.php(47): zcDate->__construct()
#3 /admin!/includes/application_top.php(42): require('...')
#4 /admin!/login.php(8): require('...')
#5 /admin!/index.php(11): require('...')
#6 {main}
thrown in /includes/classes/zcDate.php on line 90

[09-May-2024 13:32:46 UTC] Request URI: /admin!/index.php?cmd=login&camefrom=index.php, IP address: xxxxxxx
--> PHP Fatal error: Uncaught IntlException: datefmt_create: No such time zone: 'UTC': U_ILLEGAL_ARGUMENT_ERROR in /includes/classes/zcDate.php:90
Stack trace:
#0 /includes/classes/zcDate.php(90): IntlDateFormatter->__construct()
#1 /includes/classes/zcDate.php(39): zcDate->initializeConversionArrays()
#2 /includes/autoload_func.php(47): zcDate->__construct()
#3 /admin!/includes/application_top.php(42): require('...')
#4 /admin!/login.php(8): require('...')
#5 /admin!/index.php(11): require('...')
#6 {main}
thrown in /includes/classes/zcDate.php on line 90.

---

The part that makes your post the most difficult to troubleshoot is that line 90 of that file doesn't look anything like calling datefmt_create like the error message is suggesting. Here's the file from v158a: https://github.com/zencart/zencart/b...p#L87C1-L91C15

So what exactly is on YOUR line 90, and why is it different from released code?

Even in v2.0.0 it doesn't refer to datefmt_create anywhere close to that line: https://github.com/zencart/zencart/b...ses/zcDate.php
(Although given a few enhancements made to the 2.0 version of that file, it "might" be worth temporarily testing the 2.0 version on your 158a site, as an experiment.)

Definitely the error message you're getting about it saying "No such time zone" means that your PHP environment isn't aware of time zone defaults. So that's a PHP configuration problem. Like others have said, installing the 'intl' extension may help, and I see you've tried that with mixed results.

Your comment about Joomla recognizing it fine doesn't really make any difference here: if Joomla's not using the date functions that Zen Cart is calling then Joomla's not triggering your PHP configuration problem, so it's just hidden by non-use.

Zen Cart doesn't do any trickery. It just uses whatever PHP binary is linked to the vhost that you have configured for the domain you're running the site on. So if your Abyss webserver configuration is pointing this domain to use a certain PHP binary, that's what Zen Cart will run with ... and it will expect that PHP's configuration (installed extensions, ini file contents, etc) to be correct. Zen Cart doesn't do anything fancy with it: it just expects a correctly configured PHP.

[B]The file is exactly the same and on line 90 is IntlDateFormatter::NONE Attachment 20615


I tested the 2.0 file and gives the same error on line 92

The 'intl' extension was installed all along.

I refer the issue to the source of the PHP and I am waiting for their comments.

Quote:

---

Originally Posted by Georgecy

Hi Guys,
timezone-identifiers available from @lat instructions are listed at the end. The important for my case is Asia/Nicosia, Europe/Athens, which are available.( Running Joomla 4 system report, on same PHP, it shows also Europe/Nicosia and UTC as default timezone. Joomla has no problem with the PHP 8.1.1).

The actual timezone declared in php.ini is date.timezone = "Europe/Athens"

The Intl extension is also available.
I entered also in php.ini
[intl]
intl.default_locale = el_GR.UTF-8 which it had no effect on the issue.

Attached also screenshot From info.php
Attachment 20608

Asia/Aden, Asia/Almaty, Asia/Amman, Asia/Anadyr, Asia/Aqtau, Asia/Aqtobe, Asia/Ashgabat, Asia/Atyrau, Asia/Baghdad, Asia/Bahrain, Asia/Baku, Asia/Bangkok, Asia/Barnaul, Asia/Beirut, Asia/Bishkek, Asia/Brunei, Asia/Chita, Asia/Choibalsan, Asia/Colombo, Asia/Damascus, Asia/Dhaka, Asia/Dili, Asia/Dushanbe, Asia/Famagusta, Asia/Gaza, Asia/Hebron, Asia/Ho_Chi_Minh, Asia/Hong_Kong, Asia/Hovd, Asia/Irkutsk, Asia/Jakarta, Asia/Jayapura, Asia/Jerusalem, Asia/Kabul, Asia/Kamchatka, Asia/Karachi, Asia/Kathmandu, Asia/Khandyga, Asia/Kolkata, Asia/Krasnoyarsk, Asia/Kuala_Lumpur, Asia/Kuching, Asia/Kuwait, Asia/Macau, Asia/Magadan, Asia/Makassar, Asia/Manila, Asia/Muscat, Asia/Nicosia, Asia/Novokuznetsk, etc...., Europe/Amsterdam, Europe/Andorra, Europe/Astrakhan, Europe/Athens, Europe/Belgrade, etc....

---

It seems your PHP compilation is missing ICU timezone data.
Here is what I get (ICU TZData version):
Attachment 20617

In PHP there are two time zone objects, DateTimeZone that you tested with lat9 test and IntlTimeZone. Normally Intl DateFormatter can use both, but it is possible that when it is not explicitly written in code, default might be IntlTimeZone that uses ICU time zone data missing in your PHP.
This might be your problem, not 100% sure though.

You can try this code to test if ICU time zone data are here:

PHP Code:

---

<?php
$zone_iter=IntlTimeZone::createEnumeration('GR'); // Create timezone iterator. To list one country time zones, use country code : 'Au', 'US', 'Fr', 'jp' ... For all countries, use NULL.
$zone_iter->rewind();
while($zone_iter->valid()){
    echo $zone_iter->current() . "\n";
   $zone_iter->next();
}
?>

---

You should get Europe/Athens if data are here, if not an error code or nothing.
You can replace 'GR' by 'CY' for Cyprus.

Hi Guys Thanks a lot for the support,
Finally I got today the requested PHP 8.1.28. With a note from the developer as follows

"It should solve all the PHP Intl extension issues you have experienced.
The problem was that for some obscure reasons, the Intl extension
shipping with all our packages were not able to read its localization
and timezone data despite it being available as a library."

After applying the @setlocale(LC_TIME, ['en_US', 'en_US.UTF-8', 'en-US']); in configures we are back in Business.
The developer recommended to use PHP8.2+ and I will test the latest version as soon as I receive it.

Now is it recomended to skip ZC 1.5.8 and upgrade straight to ZC 2.01 from ZC1.5.7d? Or is safer to go to 1.5.8a for more compatibility?

Thanks a lot again.

> Now is it recomended to skip ZC 1.5.8 and upgrade straight to ZC 2.01 from ZC1.5.7d?

Yes.