Installation error: Failed to set timezone

[taj]

When I run the installation, I get to "install modules" and get the following error:

An error occurred during installation...

You can use the links on the left column to go back to the previous steps, or restart the installation process by clicking here.

1. Failed to set timezone

The timezone I choose in installation is the same as the server. What am I missing?

Edited October 12, 2024 by taj

[DRMasterChief]

Hi,  try another timezone and/or country!  You can change this later in Backoffice to the correct settings.

[speedy30bees]

Ok the Europe / France works with no issue.  Now this problem has been going on for a long time.  And it's not a simple change in the back office because taxes etc are tied to it.  Has anyone found a timezone that work in the US?

Now my php isn't my cup of tea but I like ThirtyBees over prestashop because of the advanced stock management.  Now with AI this fix should be fail simple.  Also, as someone else said the are internal timesones in php now to a simple class to replace to tables should work.  But for ThirtyBees to get a better foot in the market in the US this is a neceassity. 

Has anyone done the commandline install for a US timezone?  Did it work?  My guess is it didn't.

[Lucas Thomas]

The Europe/France workaround suggests the installer's timezone list is rejecting US identifiers before the database step ever runs. If the CLI install uses the same validation, a US zone likely fails there too, so testing it wouldn't tell you much. A safer approach might be to check which timezone value the installer actually writes and whether the server's PHP build recognizes that identifier, since internal PHP timezones changed across versions. Worth confirming that before assuming a back-office change would break tax rules tied to the original setting.

[Lucas Thomas]

The Europe/France workaround pointing to installer-side validation rather than a database issue makes sense. Since internal PHP timezones have shifted across versions, I'd want to confirm whether the installer is rejecting the identifier itself or failing to match it against its own list before the DB step. That would separate a mapping bug from a PHP version mismatch. If it's the former, a US identifier might be fixable without touching anything tied to tax settings, which would matter for US shops.

[ethanwright]

The point about separating installer-side validation from a PHP version mismatch is worth pursuing. Before running a CLI install with a US identifier, I'd check the array or validation rule the installer uses to build its timezone list and see whether a zone like America/New_York is present in it. If it is, the failure is likely a matching issue; if not, it's a list problem. Also confirm the PHP build's supported identifiers, since those changed across versions. That distinction should tell you whether tax settings tied to the current value are even at risk.

[speedy30bees]

On 11/8/2026 at 10:37 AM, Lucas Thomas said:

The Europe/France workaround suggests the installer's timezone list is rejecting US identifiers before the database step ever runs. If the CLI install uses the same validation, a US zone likely fails there too, so testing it wouldn't tell you much. A safer approach might be to check which timezone value the installer actually writes and whether the server's PHP build recognizes that identifier, since internal PHP timezones changed across versions. Worth confirming that before assuming a back-office change would break tax rules tied to the original setting.

Is there a command to run to identify this issue or do I need to go with a debugger?  Like I said I'm a dotnet guy but claude might be able to figure this out.  I'm going to try to figure this out but you guys are a whole heck of a lot more advanced than i especially being a php nubbie.

[speedy30bees]

It didn't take AI long to fix it.  But I completely eliminated the time zone table with a new class that handles the calls to the old time zone in the table.  Their maybe an issue if someone uses a direct sql call of the time zone table. pointer for backwards compatibility.  It needs more testing but installed just fine with America\New York time zone.