laravel-timezone
laravel-timezone copied to clipboard
jamesmills
Returning Carbon instances when using Model Casting
Custom Cast - https://laravel.com/docs/8.x/eloquent-mutators#custom-casts
Add a new way to handle user timezone dates.
When used on the Eloquent, it automatically transforms the value into a Carbon instance with the user timezone applied.
I'm a huge fan of your work here! 😂 Quick look around doens't raise any concern, sounds good! 👍
Sorry, late to the party @jpmurray
I do like the look of this.
Forgive me, I've been out of the Laravel world for a while. Is the addition of this going to break the default usage or is it just an added optional feature? I cannot remember what the Casts thing actually does but my initial thinking is it's just an added additional feature that can be used or ignored?
Also love the trait TimezoneTrait -> protected function getUserTimezone refactor @amandiobm ;-)
Let's get this in!
So this would remove all the need for us to format the date/time because it would just be an instance of Carbon with the correct timezone set. I love this. Maybe what I should have done with the main package....
I think there may be an issue with the logic here. When using the cast on the updated at attribute, the set function is called through touch() which creates a new Carbon object via ::now(). This object will have the current timezone of your app, or server, rather than the local timezone. This current object/timezone will then be passed through the convertFromLocal method which will re-parse that object as your local timezone and convert it again to UTC.
The end result is, if for example you are currently UTC+1 (UK daylight savings) but your server is configured for UTC, if you perform an action at 10:30am, the touch timestamp will be 9:30am, and after convert from local it will be recorded at 8:30am.
As far as I can tell, the set function doesn't provide enough info to determine if it was real local timezone, or one of these server generated ones.
