This has been proposed and turn down many times before: #4018, #3937, #3882, #3792, #3713

I'm not really seeing a reason not to provide it. None of the tickets you point to actually provide a valid reason for not making this change, It's backward compatible, it's simple, it allows folks to be able to switch away from UTC on an app by app basis without having to hand edit the app.php.

Setting for "app by app" basis should not be in .env.. The whole point of
the .env is for "environment" specific setting that could change for the
single app. Any setting that are constant for the application no matter
the env should be set in the appropriate app config files.

On Mon, Nov 7, 2016 at 10:59 AM, David Dierker notifications@github.com
wrote:

I'm not really seeing a reason not to provide it. None of the ticket you
point to actually provide a valid reason for not making this change, It's
backward compatible, it's simple, it allows folks to be able to switch away
from UTC on an app by app basis without having to hand edit the app.php.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4034 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA2C1THMdUkUuecTpIcrUYZPiRVU7m6cks5q71j6gaJpZM4KrbXd
.

Setting for "app by app" basis should not be in .env.. The whole point of
the .env is for "environment" specific setting that could change for the
single app. Any setting that are constant for the application no matter
the env should be set in the appropriate app config files.

A primary and valid reason for allow this change to config/app.php is that it directly effects log file rotation.
the config/app.php already has env values for changing out log file setup

'log' => env('APP_LOG', 'single'),
'log_level' => env('APP_LOG_LEVEL', 'debug'),

yet if you switch APP_LOG to daily in your .env you wind up having UTC timestamps on the log file which can prove to be naturally confusing.

If you're going to support .env values for these settings why not timezone?

The reason the env exist for log rotation is because you don't normally rotate logs on the the same schedule from dev -> prod.

I do see how someone could be a little confused on the UTC timestamps for the logs. This maybe should be cleared up with a little documentation.

The reason the env exist for log rotation is because you don't normally
rotate logs on the the same schedule from dev -> prod.

Same answer could/would apply to timezone... You might not be using the same timezone between dev and production. Heck you might not be using the same timezone on different instances of the same "app" installed to different environments/instances

I reiterate: It's a backward compatible, one line change.