Skip to content

[11.x] remove APP_TIMEZONE environment variable #6536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 12, 2025

Conversation

browner12
Copy link
Contributor

force the timezone to be defined in the config file, rather than deferring to an environment variable.

IMO having the timezone dependent on an environment variable adds an unnecessary amount of risk for your average user who may be unaware of the effects from changing this value.

some scenarios where this could cause issues:

  • devs set this value to their local timezone on their local dev machines, and they are writing Carbon:create() commands or similar that now are working only under the assumption of that timezone value
  • you have multiple production servers setup across the country and each has their own timezone value according to their location, but they all talk to a central database. now the database is loaded with mixed timezone values

having an explicit value defined once for the application removes these risks.

reverts part of #6188

force the timezone to be defined in the config file, rather than deferring to an environment variable.

IMO having the timezone dependent on an environment variable adds an unnecessary amount of risk for your average user who may be unaware of the effects from changing this value.

some scenarios where this could cause issues:

- devs set this value to their local timezone on their local dev machines, and they are writing `Carbon:create()` commands or similar that now are working only under the assumption of that timezone value
- you have multiple production servers setup across the country and each has their own timezone value according to their location, but they all talk to a central database. now the database is loaded with mixed timezone variables

having an explicit value defined once for the application removes these risks.

reverts part of laravel#6188
@taylorotwell taylorotwell merged commit 79a94de into laravel:11.x Feb 12, 2025
6 checks passed
@browner12 browner12 deleted the AB-env-example-timezone branch February 12, 2025 16:21
@a-h-abid
Copy link

Funny, it was added after long request by various users, now its revert back to old way.

Expect more PR requests for adding it back again. 😮‍💨

@GrahamCampbell
Copy link
Member

People can just edit their own config file to their preference, and pull things from env variables if they want. The framework can keep with best practice and good defaults.

@ItsRD
Copy link

ItsRD commented Mar 21, 2025

Maybe this is something that should be added to the upgrade guide — I guess the one for upgrading from 11 to 12?

In my case, I used Laravel Shift to upgrade my project from 10 to 11 a while back, which deleted my config/app.php file. After upgrading to Laravel 12 yesterday, I noticed that the dates were incorrect. The APP_TIMEZONE was previously set to Europe/Amsterdam, but the dates were in UTC. That’s when I came across this issue and added the config/app.php file back into my project.

@CoolGoose
Copy link
Contributor

I think this is a problem for shift @ItsRD , on a framework update, laravel doesn't update your config files

@ItsRD
Copy link

ItsRD commented Mar 25, 2025

@CoolGoose When Laravel 11 was released, did newly installed Laravel application have the config/app.php file installed? I thought they didn't. If so, people are going to have this issue when upgrading their Laravel application to the newest 11 or even 12 version, right? Manually or by using Laravel Shift.

@CoolGoose
Copy link
Contributor

@ItsRD fair enough, I had the impression it was published, as 12 install via the starter package did had it, so indeed if it's a case of 'it wasn't already in the 11 base install' and this changed, documenting it would be necessary :)

@wjvankesteren
Copy link

wjvankesteren commented Apr 4, 2025

Still, this change looks strange to me.

Other settings remains in the .env file, e.g. the database connection, which could have a specific timezone set which will be reflected in the .env variable APP_TIMEZONE. It will be strange at that point to have to change code for that.

Secondly, it is simply not consistent: some settings can be overriden by .env settings and some not; very strange

@browner12
Copy link
Contributor Author

some things should not be overwritten at the environment level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants