whitecube / laravel-timezones
Store UTC dates in the database and work with custom timezones in the application.
Fund package maintenance!
whitecube
Installs: 36 248
Dependents: 1
Suggesters: 0
Security: 0
Stars: 96
Watchers: 1
Forks: 10
Open Issues: 0
Requires
- php: >=8.1
- laravel/framework: ^9|^10|^11
- nesbot/carbon: ^2.64|^3.0
Requires (Dev)
- mockery/mockery: ^1.6
- pestphp/pest: ^2.34
README
Dealing with timezones can be a frustrating experience. Here's an attempt to brighten your day.
The problem: it is commonly agreed that dates should be stored as UTC
datetimes in the database, which generally means they also need to be adapted for the local timezone before manipulation or display. Laravel provides a app.timezone
configuration, making it possible to start working with timezones. However, changing that configuration will affect both the stored and manipulated date's timezones. This package tries to address this by providing a timezone conversion mechanism that should perform most of the repetitive timezone configurations out of the box.
// Model: protected $casts = [ 'occurred_at' => TimezonedDatetime::class, ]; // Set a custom timezone Timezone::set('Europe/Brussels'); // Display dates stored as UTC in the app's timezone: // (database value: 2022-12-13 09:00:00) echo $model->occurred_at->format('d.m.Y H:i'); // Output: 13.12.2022 10:00 // Store dates using automatic UTC conversion: $model->occurred_at = '2022-12-13 20:00:00'; $model->save(); // Database value: 2022-12-13 19:00:00
Installation
composer require whitecube/laravel-timezones
Getting started
The app.timezone
configuration setting has to be set to the timezone that should be used when saving dates in the database. We highly recommend keeping it as UTC
since it's a global standard for dates storage.
For in-app date manipulation and display, one would expect more flexibility. That's why it is possible to set the application's timezone dynamically by updating the timezone
singleton instance. Depending on the app's context, please choose one that suits your situation best:
1. Using middleware
Useful when the app's timezone should be set by ther user's settings.
namespace App\Http\Middleware; use Closure; use Whitecube\LaravelTimezones\Facades\Timezone; class DefineApplicationTimezone { public function handle($request, Closure $next) { Timezone::set($request->user()->timezone ?? 'Europe/Brussels'); return $next($request); } }
2. Using a Service Provider
Useful when the app's timezone should be set by the application itself. For instance, in App\Providers\AppServiceProvider
:
namespace App\Providers; use Illuminate\Support\ServiceProvider; use Whitecube\LaravelTimezones\Facades\Timezone; class AppServiceProvider extends ServiceProvider { public function boot() { Timezone::set('America/Toronto'); } }
Usage
Once everything's setup, the easiest way to manipulate dates configured with the app's current timezone is to use the TimezonedDatetime
or ImmutableTimezonedDatetime
cast types on your models:
use Whitecube\LaravelTimezones\Casts\TimezonedDatetime; use Whitecube\LaravelTimezones\Casts\ImmutableTimezonedDatetime; /** * The attributes that should be cast. * * @var array */ protected $casts = [ 'published_at' => TimezonedDatetime::class, 'birthday' => ImmutableTimezonedDatetime::class . ':Y-m-d', ];
In other scenarios, feel free to use the Timezone
Facade directly for more convenience:
use Carbon\Carbon; use Whitecube\LaravelTimezones\Facades\Timezone; // Get the current date configured with the current timezone: $now = Timezone::now(); // Create a date using the current timezone: $date = Timezone::date('2023-01-01 00:00:00'); // Alternatively, set the timezone manually on a Carbon instance: $date = new Carbon('2023-01-01 00:00:00', Timezone::current()); // Convert a date to the current timezone: $date = Timezone::date(new Carbon('2023-01-01 00:00:00', 'UTC')); // Alternatively, set the application timezone yourself: $date = (new Carbon('2023-01-01 00:00:00', 'UTC'))->setTimezone(Timezone::current()); // Convert a date to the storage timezone: $date = Timezone::store(new Carbon('2023-01-01 00:00:00', 'Europe/Brussels')); // Alternatively, set the storage timezone yourself: $date = (new Carbon('2023-01-01 00:00:00', 'Europe/Brussels'))->setTimezone(Timezone::storage());
Assigning values to cast attributes
Many developers are used to assign Carbon instances to date attributes:
$model->published_at = Carbon::create($request->published_at);
This can lead to unexpected behavior because the assigned Carbon instance will default to the UTC
timezone, whereas the provided value was probably meant for another timezone. The datetime string will be stored as-is without shifting its timezone accordingly first.
In order to prevent this, it is recommended to let the Cast do the heavy lifting:
$model->published_at = $request->published_at;
The package will now treat the provided datetime string using the correct Timezone (for instance, Europe/Brussels
) and store the shifted UTC
value in the database correctly.
A more verbose (but also correct) method would be to create the Carbon instance using the Timezone
facade :
$model->published_at = Carbon::create($request->published_at, Timezone::current()); // Or, shorthand: $model->published_at = Timezone::date($request->published_at);
This is not a bug, it is intended behavior since one should be fully aware of the Carbon instance's timezone before assigning it.
Edge cases
If you need to use the TimezonedDatetime
or ImmutableTimezonedDatetime
casts on the default timestamp columns (created_at
and/or updated_at
) AND you're expecting to handle dates with timezones other than UTC or the one you've defined with Timezone::set()
, you will need to apply the Whitecube\LaravelTimezones\Concerns\HasTimezonedTimestamps
trait on your model.
This is necessary to prevent Laravel's casting of those attributes to occur, which would transform the value in a way where the timezone information is lost, preventing our cast from working properly.
An example of a case where you need to use the trait:
Timezone::set('Europe/Brussels'); $model->created_at = new Carbon('2022-12-15 09:00:00', 'Asia/Taipei');
🔥 Sponsorships
If you are reliant on this package in your production applications, consider sponsoring us! It is the best way to help us keep doing what we love to do: making great open source software.
Contributing
Feel free to suggest changes, ask for new features or fix bugs yourself. We're sure there are still a lot of improvements that could be made, and we would be very happy to merge useful pull requests. Thanks!
Made with ❤️ for open source
At Whitecube we use a lot of open source software as part of our daily work. So when we have an opportunity to give something back, we're super excited!
We hope you will enjoy this small contribution from us and would love to hear from you if you find it useful in your projects. Follow us on Twitter for more updates!