[11.x] remove APP_TIMEZONE environment variable
#6536
Conversation
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
|
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. 😮💨 |
|
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. |
support this breaking change laravel/laravel#6536
* laravel/laravel#6450 * laravel/laravel#6536 Signed-off-by: Mior Muhammad Zaki <crynobone@gmail.com>
|
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. |
|
I think this is a problem for shift @ItsRD , on a framework update, laravel doesn't update your config files |
|
@CoolGoose When Laravel 11 was released, did newly installed Laravel application have the |
|
@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 :) |
|
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 |
|
some things should not be overwritten at the environment level. |
@CoolGoose I disagree with this statement. I expect shift to be aligned with laravel standards. If you guys choose to drop it, it's not a shift issue IMHO. In terms of general discussion on this topic I also disagree with the justifications given for this change by @browner12 :
Does not make any sense at all. If your local dev environment is using another timezone throughout all data stored in local DB (which should be decoupled from any production data when it's a local dev environment) I see hardly any scenario where you would end up with something that would work in your local environment but break in production. The only two cases where this might impose issues I can think of are the following two cases:
That being said if any of the cases mentioned above cause issues I have strong feelings about this being a developer responsibility in this case.
I don't know of a single OS etc. that set To me both arguments sound like you're expecting developers / ops to be stupid and then blame the framework. If this is the way we want to move forward with laravel, we may as well revert back Lastly simply looking at the reactions on the comments in this discussion we can simply observe that this has been an unpopular change. This should be taken into consideration for future changes. |
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:
Carbon:create()commands or similar that now are working only under the assumption of that timezone valuehaving an explicit value defined once for the application removes these risks.
reverts part of #6188