How to Carbon::Parse in dd/mm/yyyy format?

You are passing a string 11/06/1990 to the parse method and you're expecting it to return the same result? Why use the method then?

If you want to get a Carbon object from a certain format, then use the createFromFormat method, such as

$date = Carbon\Carbon::createFromFormat('d/m/Y', '11/06/1990');

and now you have a Carbon object you can play around with.

As for the parse method, you can use it to create a Carbon instance from a string. This is an alias for the constructor that allows better fluent syntax as it allows you to do

Carbon::parse('Monday next week'); 

You'll want something like

$input  = '11/06/1990';
$format = 'd/m/Y';

$date = Carbon\Carbon::createFromFormat($format, $input)

@toniperic that is obviously just an example!

I did this just to check if the date stored on my carbon object was consistent to the original value.

My form accepts an field with user dob in d/m/Y format, but mysql stores in other format, then I need to convert to save, and convert back to user friendly format again.

@eliaseas you actually don't have to convert anything back and forth, as Carbon does it all automatically for you. Not even when storing to the database.

All you'd do is, when accepting your input, call a Carbon::createFromFormat('d/m/Y', $yourDateInput); and that's it.

@eliaseas You can't rely on this format in parse at all. Carbon::parse('13/11/2015') BANG error ;)

Use parse like in @toniperic 's example rather than with the known format.

As an aside, the reason PHP's date methods (by default) handle dates like 13/12/2014 as 12/13/2014 is it's native parsing using US dates. It assumes that if your date has a / as the separator, it is being given a date in format mm/dd/yyyy. If you wanted to pass an Australian/British formatted date, you could use 13-12-2014 and it should behave itself.

Like @toniperic states above, the parse method is for taking a string of common date parlance like Carbon::parse('first day of December 2008') and converting it to a Carbon instance.

I've solved by using Acessors and Modifiers in my model:

public function getDobAttribute($value)
    {
        return Carbon::parse($value)->format('d/m/Y');
    }

    public function setDobAttribute($value)
    {
        $this->attributes['dob'] = Carbon::createFromFormat('d/m/Y', $value)->toDateString();
    }

Any problem with this? So I will aways just get and set the date. Of course that before setting, my controller validates if the date is in right format.

Try ommiting the setDobAttribute method. If you've done everything correctly and the field in the table is of correct type, it should work out of the box.

@toniperic

No, it does not work properly.

What I've done wrong?

In your table, what type is the 'dob' field?

I highly recommend you watch the Dates, Mutators, and Scopes screencast that was released few days ago.

@toniperic It wouldn't work without the mutator. @eliaseas What is not working?

@JarekTkaczyk right, my bad.

My code with Acessors and Modifiers is working properly.

You do not need the accessors and mutators. The date will properly be stored and converted on output so long as you add the field to your $dates property on your model.

class User extends Model {

    protected $dates = ['dob'];
}

If you do this you will be able to remove your mutators and so long as your field in your database is a "date" field things will work fine. This is how the created_at, updated_at, etc are done. The only thing $dates does is add your custom field to that list of fields that gets parsed on in/out as a date. You may optionally keep your accessor if you prefer your date to be always be returned as a string in a certain format though; but I generally avoid doing this because I would rather my model return a carbon instance so that I can output the date in whatever format I wish depending on where I am in the application.

For example, if you removed your accessor then anytime you called $user->dob then a carbon instance would be returned, this would allow you to do things like this in your views:

Date of Birth: {{ $user->dob->format('m/d/Y') }}

And then maybe somewhere else you want a different format:

Date of Birth: {{ $user->dob->format('Y-m-d') }}

Having the Carbon instance also gives you access to all of Carbon's other features, a useful one for a birthday might be how many years it's been since their birthday:

Age: {{ $user->dob->diffInYears(Carbon::now()); }}

If you leave in your accessor (which I don't recommend because then you're just returned a string), you no longer need to create the carbon instance and you could do something like this:

function getDobAttribute()
{
    return $this->attributes['dob']->format('m/d/Y');
}

@Jeffberry Close, but not there yet - if you are using $dates:

1. First off, you can't do it without mutator, because of the different format to the default, that Eloquent uses:

$user->dob = '11/12/2013'; // BANG (like already mentioned above)

// while eloquent tries explicitly:
Carbon::createFromFormat($format, $value); // format comes from the Grammar used by the connection

1. For the accessor, yep, you're right, leaving the Carbon instance instead of format(whatever) may come in handy. So either use $dates + mutator, or accessor + mutator, no other way.

@JarekTkaczyk "Close but not there yet?" This is the second time you've used a condescending tone with me as if I'm some amateur. I told you the first time around your attitude is not appreciated. You sir are close, but you just aren't quite there. Keep fishing.

1. You can absolutely do it without a mutator. Please reference the API if you are unaware of this. Will he optionally need a mutator if he chooses to use a different format? Yes, that is why it is called a mutator, because you are mutating the format to a mutated format other than that which was inputted. However, for any and all $dates fields Eloquent will automatically handle the input of:
   • A DateTime (Carbon) object
   • A numeric timestamp
   • A date in the format of Y-m-d
   • A date following Eloquent's default dateFormat for that model, which by default is taken from the Database Grammar and can be overridden by doing this (as referenced in Eloquent's docs):

protected function getDateFormat()
{
    return 'm/d/Y';
}

1. You can set and receive dates using nothing but $dates at all. This is proven in my projects several times over again.

His options are he can either use $dates and simply input dates or he can use $dates and (mutators|accessors) if he wishes to customize the format for any reason, just like you optionally use mutators and accessors if you customize the format of any other field. However the absence in this case allows him to customize the format anywhere the field is outputted and it also allows him to input the date in several alternate ways -- whereas his mutator would limit it to m/d/Y

Again, I don't know what it is you have for me but I don't appreciate the attitude that you face me with for the second time now. I think we can get along fine, let's just start over fresh from here but please do not use this condescending tone with me as if I am some inferior student of yours that's just over here throwing bananas.

Doesn't the getDateFormat set the format for all date fields? The mutator is likely the right option for this specific case, whilst the default format is fine for everything else.

@deringer you are correct. getDateFormat sets the format for the timestamps of all fields on the model. I'm not assuming his environment (maybe his table has no other dates, maybe he wishes all other dates be the same format). The option is simply listed as one of the ways in which this can be done (mind you I listed it as the third and last alternative as well). The mutator is probably the right method if he wishes to input a foreign date that deviates from the standard to Eloquent. However he could easily pass it a standardized format such as Y-m-d, a timestamp, or a DateTime/Carbon object (which is probably the most programatic way anyway).

@Jeffberry Don't take it too serious mate. You're suggesting something that isn't correct in terms of Eloquent API.

I don't have anything for you personally. I didn't like your attitude in the first conversation we had, because, well it was something like: whaaaat? Use Eloquent, not joins. Because I say so! - so I have just shown you why this might not be the best idea in the end. Despite I'm real fan of Eloquent and, as you can see, I know its ins and outs.

Back to the topic - again, it's not about whether something will work if X, Y, Z, but rather whether it work in this very case. That is, whether it answers the question OP stated above. And, again, your suggestion, which is... You don't need this, you don't need that, just do as I say, is wrong, because without mutator (or overriding getDateFormat of which I'm perfectly aware, as you could have noticed in one of recent conversations) calling $model->dob = 'my/custom/dateFormat' will throw InvalidArgumentException.

@deringer Correct, it will set the format for:

1. all accessors, so all the mutated dates on this model will be in that format (created_at, updated_at and other $dates)
2. all date mutators

I agree, using Y-m-d is preferable but it's not always something the user will do (or want to do), particularly for those like @eliaseas and myself where our users are used to d/m/Y. We can use date pickers and the like but users like to see what they're familiar with.

You could mess around with hidden fields that set the preferred format, but you're messing around somewhere. My personal preference would be to make it user friendly, and handle it from the mutator perspective.

@Jeffberry, @JarekTkaczyk - sometimes it's better to address the question rather than providing personal opinions or best practices it can often lead to confusing the person asking the question, flame wars, or both.

You guys both contribute a lot of valuable answers here from what I've seen - keep up the great work!

@JarekTkaczyk please do not bring the other conversation into this. I am very well aware of that fact that you asked to hear how it could be solved in Eloquent and then you attacked every word of what I said. You don't need to repeat the charade.

You come through with the attitude of You're wrong. You're wrong. You're still wrong. You're wrong I'm not even sure you read the posts, you are definitely a very close-minded person, well at least biased and closed to my input anyway. You have quite the ego too, saying "as you can see, I know it's ins and outs". I know Eloquent very well too my friend, I'm just not here to show my feathers to you. I know what I am capable of and I know that it is either on par or far beyond what you may be capable of. We ain't roosters man, put your feathers away.

My solution is not only correct in terms of Eloquent's API, it is by definition of the API the correct way to do it. Please reference the API if you are unfamiliar.

My solution will work in this very case, and it will work in several other cases of his application. The fact is he just does not need accessors or mutators. There are four built-in ways in which he can set a date. You want to stack something on top of it which will limit him to one? You don't need the mutator, and you don't need to override getDateFormat -- the fact is it will just work. Yes, setting the date to a custom format (other than the three natively supported formats) will throw an exception, just as setting a string to an integer column with throw an exception. Are you going to place mutators on every single property you have to validate that it's a string first? No. You are going to pass it a string. He should pass it a date.

@deringer I'm not even thinking the format of the date needs to come from HTML datepickers or hidden fields, I would imagine that either

• In his repository he would standardize the date to a DateTime/Carbon object, a format of Y-m-d (which is a standard), or even a timestamp before he sends it to Eloquent, or:
• In his Command/ServiceClass he would standardize the format in the same ways as above.

The fact is, we are cognizant of our formats when we are setting other values to Eloquent (i.e we don't set strings to integer columns) and this should be no exception.

No doubt he would standardise the format of the date somewhere, if it's a simple application, the model may well be the most convenient place to do it. End of the day, you still have to account for the format your users are going to enter the date and convert it accordingly.

@Jeffberry Yep, you're right. Your way is not only correct, but the correct. You missed only one detail - it doesn't work.

protected $dates = ['dob', 'dob_no_mutator'];

/**
 * Mutator for dob property
 *
 * @return void
 */
public function setDobAttribute($value)
{
    $this->attributes['dob'] = Carbon::createFromFormat('d/m/Y', $value);
}


[1] > $user = new User;
// object(User)(
//   'incrementing' => true,
//   'timestamps' => true,
//   'exists' => false
// )
[2] > $user->dob = '11/12/2013';
// '11/12/2013'
[3] > $user->dob;
// object(Carbon\Carbon)(
//   'date' => '2013-12-11 12:20:35',
//   'timezone_type' => 3,
//   'timezone' => 'Europe/Warsaw'
// )
[4] > $user->dob_no_mutator = '11/12/2013';
PHP Fatal error:  Uncaught exception 'InvalidArgumentException' with message 'Unexpected data found.
Unexpected data found.
Data missing' in /PATH/vendor/nesbot/carbon/src/Carbon/Carbon.php:385
Stack trace:
#0 PATH/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php(2634): Carbon\Carbon::createFromFormat('Y-m-d H:i:s', '11/12/2013')
#1 PATH/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php(2566): Illuminate\Database\Eloquent\Model->fromDateTime('11/12/2013')
#2 PATH/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php(3022): Illuminate\Database\Eloquent\Model->setAttribute('dob_no_mutator', '11/12/2013')
#3 PATH/vendor/d11wtq/boris/lib/Boris/EvalWorker.php(133) : eval()'d code(1): Illuminate\Database\Eloquent\Model->__set('dob_no_mutator', '11/12/2013')
#4 PATH/ in /PATH/vendor/nesbot/carbon/src/Carbon/Carbon.php on line 385

Really, I'm nice guy and I'm eager to help anyone asking for advice. It's just, I see programming great, because there are always many ways to achieve your goals and I really don't like when people claim they just know better so you either follow them, or you're wrong..

Didn't you notice I had said you had been absolutely right about returning Carbon instead of already formatted string - that was definitely good advice. It wasn't right or wrong, you just made a fair point there.

@JarekTkaczyk You're right, your test clearly shows it doesn't work. You missed only one detail -- your test is not even close to the way I said it could be done (or even the way it should be done). But you knew that, didn't ya? ;)

My god man, you are twisting my words into a way which is not correct in order to show me that I'm not correct. DID I POST THAT m/d/Y WAS AN APPROVED FORMAT? No. I have NOT ONCE said that. If your test actually implemented any of the actual four methods I stated then you are guaranteed a successful result.

I'm not claiming I know better -- you came on here telling me "close, but not there yet" as if you know better. The attitude in which you say you hate I am getting from you. You really think you're being a nice guy to me? This is the second time you've stomped through a thread to go out of your way to insult me.

Let me educate you:

use Illuminate\Database\Eloquent\Model;

class Test extends Model {

    protected $dates = ['dob'];
}

$test = new Test;

$test->dob = Carbon::parse('September 13, 1922');

echo $test->dob; // 1922-09-13 00:00:00

$test->dob = '1922-9-13';

echo $test->dob; // 1922-09-13 00:00:00

$test->dob = strtotime('September 13, 1922');

echo $test->dob; // 1922-09-13 00:00:00

Heh, I must be slightly better at programming than you, I was able to set the date in three different ways without firing an exception?

This is why I find you to be quite an asshole right now, definitely not a "nice guy". You chose to test the only format which I didn't state was acceptable to prove that I was wrong because you know every other option was correct. There is no other explanation for why you chose to test the only option you knew would fail. An option that I never even stated would work. You simply wanted to prove me wrong even if you were proving me wrong for something I was not wrong about. You are not being helpful to the community or the original poster at all, you are simply fishing for a way to put me down.

Don't try and patronize me now telling me that you said I was correct about returning a Carbon instance. I am also correct in the other parts of what I am saying -- if you are too novice to understand why, then so be it, but as a student you need to have a better attitude towards learning other than your current I know better and this is the way it should be done. The fact is what the original poster is trying to do can be done in numerous different ways (as I have just proven with my code snippet) without the need to add hackish mutators onto his model.

I'm through with you. I already told you in the first conversation that I would steer clear from you because I did not like your attitude. I especially do not like your attitude in this conversation. I will avoid conversation with you throughout the rest of this forum and I ask that you please do the same.

Yep, you're the man.

To be fair, the format @JarekTkaczyk tested with and didn't work is one format that @eliaseas was trying to use.

It appears he was just trying to illustrate that for the OP's needs, what you were suggesting wasn't going to work and that's ok. Multiple solutions have been shown and I think OP is happy with the solution they've been offered and works for them, before the thread got derailed.

Don't be surprised by my response man. You knew what you were doing when you posted that. You knew you were running a test that would fail even though it was not one of the methods I stated. You also knew it wasn't one of the methods I stated. What you didn't know was this ain't my first rodeo ;) I'm not some novice stumbling around here that you can walk all over. I can hold my own, especially against someone as damaging to a community as yourself.

@deringer thanks for your neutralism here. The topic needs cooled down a little bit :) JarekTkaczyk's test had nothing to do with the original post unfortunately, it was purely out of spite towards me. He knew that.

That will be the end of it for me though -- good luck to the original poster. My only thing is we are all students all of the time. We should never stop learning. The original poster shouldn't just accept an answer and move on if he really is passionate about programming, he should be asking why and how. Understanding the inner workings of Eloquent such as it's native date handling is very valuable, and I hope he learns a little bit about Eloquent from this thread (if he chooses to read through all of our bullshit :/).

Thanks gentlemen! I'm off.