Download the PHP package whitecube/laravel-timezones without Composer
On this page you can find all versions of the php package whitecube/laravel-timezones. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-timezones
Laravel Timezones
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.
Installation
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.
2. Using a Service Provider
Useful when the app's timezone should be set by the application itself. For instance, in App\Providers\AppServiceProvider:
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:
In other scenarios, feel free to use the Timezone Facade directly for more convenience:
Assigning values to cast attributes
Many developers are used to assign Carbon instances to date attributes:
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:
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 :
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:
🔥 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 Twitter for more updates!
