Question: How to get formatted date in user's timezone? about carbon

[veloace]

Though this is old, it's also important to note that this also works:

$carbon->tz('America/Chicago')->toDayDateTimeString()

Nice shorthand that may be handy for things like working with a saved database value in a Laravel Blade template. For example, I have a user activity log and, rather than iterating through in the controller to set all the dates, I can just have it in the blade template like this:

      @foreach($activities as $activity)
                        <div class="card">
                            <div class="card-header">
                                <div class="card-title h5">Activity on {{$activity->created_at->tz('America/Chicago')->toDayDateTimeString()}} CST</div>
                            </div>
                            <div class="card-body">
                                <p>{!!$activity->action!!}</p>
                            </div>
                        </div>
                        <div class="divider"></div>
                    @endforeach

That way, you can just pass the model collection straight to the controller.

[briannesbitt]

$carbon = Carbon::createFromFormat('Y-m-d H:i:s', 'UTC');   // specify UTC otherwise defaults to locale time zone as per ini setting
$carbon->tz = 'America/Toronto';   // ... set to the current users timezone

echo $date->format('Y-m-d @ H:i');  // output in users timezone

If you need to keep the original instance you can use the copy() in there to make a copy before setting the tz.

[eliysha]

If it can help someone, correct syntax is otherwise you'll get a format error

$carbon = Carbon::createFromFormat('Y-m-d H:i:s', $date, 'UTC');   // specify UTC otherwise defaults to locale time zone as per ini setting
$carbon->tz = 'America/Toronto';   // ... set to the current users timezone

echo $date->format('Y-m-d @ H:i');  // output in users timezone

[bhattraideb]

I have a situation wherein database all DateTime are stored in UTC and in the browser, I have to change DateTime according to client's browser timezone like if user check from the US it should be converted to UST and if from India it should be converted to IST. How can I achieve this? Does anyone face this? I appreciate any clue.

[kylekatarnls]

I wrote tutorials about it:

A PHP/Carbon one:
https://medium.com/@kylekatarnls/handle-dates-the-right-way-in-php-c215650fc4fa

And a more generic about timezones:
https://medium.com/@kylekatarnls/always-use-utc-dates-and-times-8a8200ca3164

By having your DateTime in UTC in your database, you've got a very good start.

Now basically, you can change the timezone server-side (if the server now the client timezone), using ->tz() as in the example above, your send the date with the ISO format Y-m-d\TH:i:s\Z (method ->toJSON(), the magic part is you pass Z at the end meaning UTC+00:00 then if you do new Date(isoString) in JavaScript, it will automatically create a local date with the client timezone for the equivalent moment of the UTC input.

[emjayess]

Though this is old, it's also important to note that this also works:

$carbon->tz('America/Chicago')->toDayDateTimeString()

Nice shorthand that may be handy for things like working with a saved database value in a Laravel Blade template. For example, I have a user activity log and, rather than iterating through in the controller to set all the dates, I can just have it in the blade template like this:

      @foreach($activities as $activity)
                        <div class="card">
                            <div class="card-header">
                                <div class="card-title h5">Activity on {{$activity->created_at->tz('America/Chicago')->toDayDateTimeString()}} CST</div>
                            </div>
                            <div class="card-body">
                                <p>{!!$activity->action!!}</p>
                            </div>
                        </div>
                        <div class="divider"></div>
                    @endforeach

That way, you can just pass the model collection straight to the controller.

@veloace : In this Laravel+blade use case, I would advise relocating that time(zone)-shifting logic into a model attribute accessor, to keep the blade syntax simpler and "dumber" – a noble objective...

In Activity.php's model definition...

public function getCreatedAtAttribute($createdAtUTC)
{
    return $createdAtUTC
        ->tz('America/Chicago')
        ->toDayDateTimeString()
    ;
}

This may be further improved, if you have the desired timezone set in /config/app.php (or it could also be some preference per user):

/*
|--------------------------------------------------------------------------
| Application Timezone
|--------------------------------------------------------------------------
|
| Here you may specify the default timezone for your application, which
| will be used by the PHP date and date-time functions. We have gone
| ahead and set this to a sensible default for you out of the box.
|
*/

'timezone' => 'America/Chicago',

Then tweak the attribute accessor as follows:

public function getCreatedAtAttribute($createdAtUTC)
{
    $localTZ = config('app.timezone');

    return $createdAtUTC
        ->tz( $localTZ )
        ->toDayDateTimeString()
    ;
}

And with that, access it in blade templates (or anywhere in any other application code) as a plain attribute:

<div class="card-title h5">
  Activity on {{ $activity->created_at }} CST
</div>

For even better readability/semantics, another attribute accessor 'facade' could also be used:

public function getTimestampCSTAttribute()
{
    return $this->created_at . ' CST';
}

<div class="card-title h5">
  Activity on {{ $activity->timestamp_cst }}
</div>

[kylekatarnls]

I wouldn't promote this approach. As explained the articles I linked in my previous comment, having 'timezone' => 'America/Chicago' means your basically support only 1 timezone properly and make everything more difficult to calculate/format dates in other timezones if you need (now or in the future) to scale on a multi-timezones support, exchange/format dates for external services or users across the world. Moreover, if you pick a timezone with DST like "Chicago", you will likely encounter bugs with DST, such as storing 1 nov 2020 1h30 (when having this data in your DB, you don't know if it's the 1h30 after or before the DST change, so you can't properly order messages/posts/things in this range, and even worst, this will also happen for users in the rest of the world because you store "Chicago" for everybody). To be short, if you don't want to hate yourself or be hated by the next developer, use 'timezone' => 'UTC'. You will still be able to have an extra application setting such as "default_format_timezone" which could be the timezone you use to display a date when you don't know the user timezone. And everything will be way easier to internationalize to and adapt properly to the correct user timezone.

Then when accessing getCreatedAtAttribute you should not enforce a particular timezone. This is data-loss (date => string cast, precision decrease, and implicitly shift the timezone). You should rather keep the data integrity so any Carbon method can still be called on the object and customize the formatting to do when casting to string:

public function getCreatedAtAttribute($createdAtUTC)
{
    return $createdAtUTC->settings([
        'toStringFormat' => function ($date) {
            // Try to get a timezone that actually make sense for the user in Auth::user() settings
            // or browser timezone retrieved via a cookie/header/HTTP parameter, guess it from IP, etc.
            // else fallback to a custom setting to add in your /config/app.php file such as default_format_timezone
            // /!\ a dedicated one, not the "timezone" one which is also used for the DB storing and should remain
            // UTC for better scallability
            $userTimezone = config('app.default_format_timezone');

            return $date->tz($userTimezone)->toDayDateTimeString().
                ' '.
                $userTimezone;
        },
    ]);
}

With this, you can:

<div class="card-title h5">
  Activity on {{ $activity->created_at }}
</div>

This will show "Fri, Jun 19, 2020 1:39 PM CST" if default_format_timezone is set to CST

But you're still able to use date methods or to customize it in templates:

<div class="card-title h5">
  Activity on {{ $activity->created_at->addDays(5) }} ← the new date (created_at + 5 days) will inherit the toStringFormat
  Activity on {{ $activity->created_at->tz('Europe/Paris')->toDayDateTimeString() }} (Paris)
  Activity on {{ $activity->created_at->diffForHumans() }}
</div>