Member Since 2 Years Ago
2,580 experience to go until the next level!
In case you were wondering, you earn Laracasts experience when you:
Earned once you have completed your first Laracasts lesson.
Earned once you have earned your first 1000 experience points.
Earned when you have been with Laracasts for 1 year.
Earned when you have been with Laracasts for 2 years.
Earned when you have been with Laracasts for 3 years.
Earned when you have been with Laracasts for 4 years.
Earned when you have been with Laracasts for 5 years.
Earned when at least one Laracasts series has been fully completed.
Earned after your first post on the Laracasts forum.
Earned once 100 Laracasts lessons have been completed.
Earned once you receive your first "Best Reply" award on the Laracasts forum.
Earned if you are a paying Laracasts subscriber.
Earned if you have a lifetime subscription to Laracasts.
Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.
Earned once you have achieved 500 forum replies.
Earned once your experience points passes 100,000.
Earned once your experience points hits 10,000.
Earned once 1000 Laracasts lessons have been completed.
Earned once your "Best Reply" award count is 100 or more.
Earned once your experience points passes 1 million.
Earned once your experience points ranks in the top 50 of all Laracasts users.
Alright, well let me break it down for you a little more.
Let's say you have a user object with a field called 'expired'. In the database, the field of 'expired' is of type Timestamp.
Simple, right? We have a column on the users table of type Timestamp.
Let's say, for instance, you integrate with a host of other systems (which I do). These systems don't all represent time the same way when communicating with my application. Some may send Unix time (1579196817), ISO 8601 ( '2020-01-16T17:46:57+00:00'), RFC 2822 ('Thursday, 16-Jan-20 17:46:57 UTC'), so on and so forth, you get the idea.
Let's say I am updating the Timestamp column 'expired' on my users table again.
// This would be great to do $user->expired = 1579196817; $user->save();
It turns out that this is actually functionality already built into Laravel! Wohoo! Mutators are great. This is what I was describing in my original post. I want a mutator to automatically cast any type of date I pass to the field on the model, that way I'm not doing
Carbon::parse() all over my project. Instead, let's do it in one spot, and make it easy to just save dates directly to the model, and back it with a Timestamp.
\App\Models\User.php // Marvelous. All we do is let Eloquent know in our model that we have an extra date field. protected $dates = [ 'expired' ];
Unless of course, you mean that the
$dates field is very strict in its definition of 'date' and that I can't use timestamps here. In which case, shouldn't there be a $timestamps field as well? I know the difference between a date and a timestamp, it's pretty obvious.
I am storing the dates as a Timestamp. There are just situations where I have Unix time, and it's annoying having to cast it everywhere to a Timestamp to push it to my models.
The previous answer I accepted was what I needed. This functionality is already built into Laravel for date mutators.
Thank you so much for this. So I have to directly specify on the model which fields are dates. I knew I could do this, because I've done it before. It was just hard to dig up the information again.
Started a new Conversation Can Eloquent Accept Unix Time For Date Fields?
I am wondering if I can configure anything on my models or environment to allow setting a date field to an integer, and having Eloquent automatically interpret this as Unix time.
At the moment, it's a bit painful to use
Carbon::createFromTimestamp($unixTime) everywhere. I would prefer just being able to set my date fields to Unix time, save, and have Eloquent handle the casting.
To be clear, I want the database type to be Timestamp, and be able to cast Unix time to a timestamp. I am seeing answers on other sites where users want to save Unix time in the database. I know how to achieve that functionality.
Exactly. You cannot have plain text passwords/secrets in log files or database records. It just so happens that my use case was with PDO throwing exceptions as well. My DB password was being stored in the failed_jobs table stack trace.
Are you asking if I'm still experiencing this issue?